336
353
modparam("rtpproxy", "extra_id_pv", "$avp(extra_id)")
358
The database URL to load rtp_proxy sets from. If this parameter is
359
set, the module will attempt to load the rtpproxy sets from the
360
specified database and will ignore any 'rtpproxy_sock' modparams.
362
Default is empty, a database will not be used.
364
Example 1.9. Set db_url parameter
366
modparam("rtpproxy", "db_url", "mysql://user:passwb@localhost/database")
369
4.10. table_name (string)
371
The name of the table containing the rtpproxy sets.
373
Default value is "rtpproxy".
375
Example 1.10. Set table_name parameter
377
modparam("rtpproxy", "table_name", "my_rtpp_sets")
341
5.1. set_rtp_proxy_set(setid)
342
5.2. rtpproxy_offer([flags [, ip_address]])
343
5.3. rtpproxy_answer([flags [, ip_address]])
344
5.4. rtpproxy_destroy([flags])
345
5.5. unforce_rtp_proxy()
346
5.6. rtpproxy_manage([flags [, ip_address]])
347
5.7. rtpproxy_stream2uac(prompt_name, count),
348
5.8. rtpproxy_stream2uas(prompt_name, count)
349
5.9. rtpproxy_stop_stream2uac(),
350
5.10. start_recording()
351
5.11. rtpproxy_stop_stream2uas(prompt_name, count)
353
5.1. set_rtp_proxy_set(setid)
355
Sets the Id of the rtpproxy set to be used for the next
356
unforce_rtp_proxy(), rtpproxy_offer(), rtpproxy_answer() or
382
5.1. set_rtp_proxy_set(setid)
383
5.2. rtpproxy_offer([flags [, ip_address]])
384
5.3. rtpproxy_answer([flags [, ip_address]])
385
5.4. rtpproxy_destroy([flags])
386
5.5. unforce_rtp_proxy()
387
5.6. rtpproxy_manage([flags [, ip_address]])
388
5.7. rtpproxy_stream2uac(prompt_name, count),
389
5.8. rtpproxy_stream2uas(prompt_name, count)
390
5.9. rtpproxy_stop_stream2uac(),
391
5.10. start_recording()
392
5.11. rtpproxy_stop_stream2uas(prompt_name, count)
394
5.1. set_rtp_proxy_set(setid)
396
Sets the Id of the rtpproxy set to be used for the next
397
unforce_rtp_proxy(), rtpproxy_offer(), rtpproxy_answer() or
357
398
rtpproxy_manage() command. The parameter can be an integer or a config
358
399
variable holding an integer.
360
This function can be used from REQUEST_ROUTE, ONREPLY_ROUTE,
401
This function can be used from REQUEST_ROUTE, ONREPLY_ROUTE,
363
Example 1.9. set_rtp_proxy_set usage
404
Example 1.11. set_rtp_proxy_set usage
365
406
set_rtp_proxy_set("2");
366
407
rtpproxy_offer();
369
5.2. rtpproxy_offer([flags [, ip_address]])
410
5.2. rtpproxy_offer([flags [, ip_address]])
371
412
Rewrites SDP body to ensure that media is passed through an RTP proxy.
372
To be invoked on INVITE for the cases the SDPs are in INVITE and 200 OK
373
and on 200 OK when SDPs are in 200 OK and ACK.
413
To be invoked on INVITE for the cases the SDPs are in INVITE and 200
414
OK and on 200 OK when SDPs are in 200 OK and ACK.
375
416
Meaning of the parameters is as follows:
376
417
* flags - flags to turn on some features.
377
+ 1 - append first Via branch to Call-ID when sending command to
378
rtpproxy. This can be used to create one media session per
379
branch on the rtpproxy. When sending a subsequent "delete"
380
command to the rtpproxy, you can then stop just the session
418
+ 1 - append first Via branch to Call-ID when sending command
419
to rtpproxy. This can be used to create one media session per
420
branch on the rtpproxy. When sending a subsequent "delete"
421
command to the rtpproxy, you can then stop just the session
381
422
for a specific branch when passing the flag '1' or '2' in the
382
"unforce_rtpproxy", or stop all sessions for a call when not
383
passing one of those two flags there. This is especially
384
useful if you have serially forked call scenarios where
385
rtpproxy gets an "update" command for a new branch, and then a
386
"delete" command for the previous branch, which would
387
otherwise delete the full call, breaking the subsequent
388
"lookup" for the new branch. This flag is only supported by
423
"unforce_rtpproxy", or stop all sessions for a call when not
424
passing one of those two flags there. This is especially
425
useful if you have serially forked call scenarios where
426
rtpproxy gets an "update" command for a new branch, and then
427
a "delete" command for the previous branch, which would
428
otherwise delete the full call, breaking the subsequent
429
"lookup" for the new branch. This flag is only supported by
389
430
the ngcp-mediaproxy-ng rtpproxy at the moment!
390
+ 2 - append second Via branch to Call-ID when sending command
431
+ 2 - append second Via branch to Call-ID when sending command
391
432
to rtpproxy. See flag '1' for its meaning.
392
+ 3 - behave like flag 1 is set for a request and like flag 2 is
394
+ a - flags that UA from which message is received doesn't
433
+ 3 - behave like flag 1 is set for a request and like flag 2
435
+ a - flags that UA from which message is received doesn't
395
436
support symmetric RTP. (automatically sets the 'r' flag)
396
+ b - append branch specific variable to Call-ID when sending
397
command to rtpproxy. This creates one rtpproxy session per
398
unique variable. Works similar to the 1, 2 and 3 parameter,
399
but is usefull when forking to multiple destinations on
400
different address families or network segments, requiring
401
different rtpproxy parameters. The variable value is taken
402
from the "extra_id_pv". When used, it must be used in every
403
call to rtpproxy_manage(), rtpproxy_offer(), rtpproxy_answer()
404
and rtpproxy_destroy() with the same contents of the PV. The b
405
parameter may not be used in conjunction with the 1, 2 or 3
406
parameter to use the Via branch in the Call-ID.
407
+ l - force "lookup", that is, only rewrite SDP when
408
corresponding session already exists in the RTP proxy. By
437
+ b - append branch specific variable to Call-ID when sending
438
command to rtpproxy. This creates one rtpproxy session per
439
unique variable. Works similar to the 1, 2 and 3 parameter,
440
but is usefull when forking to multiple destinations on
441
different address families or network segments, requiring
442
different rtpproxy parameters. The variable value is taken
443
from the "extra_id_pv". When used, it must be used in every
444
call to rtpproxy_manage(), rtpproxy_offer(),
445
rtpproxy_answer() and rtpproxy_destroy() with the same
446
contents of the PV. The b parameter may not be used in
447
conjunction with the 1, 2 or 3 parameter to use the Via
448
branch in the Call-ID.
449
+ l - force "lookup", that is, only rewrite SDP when
450
corresponding session already exists in the RTP proxy. By
409
451
default is on when the session is to be completed.
410
+ i, e - these flags specify the direction of the SIP message.
411
These flags only make sense when rtpproxy is running in bridge
412
mode. 'i' means internal network (LAN), 'e' means external
413
network (WAN). 'i' corresponds to rtpproxy's first interface,
414
'e' corresponds to rtpproxy's second interface. You always
415
have to specify two flags to define the incoming network and
416
the outgoing network. For example, 'ie' should be used for SIP
417
message received from the local interface and sent out on the
418
external interface, and 'ei' vice versa. Other options are
419
'ii' and 'ee'. So, for example if a SIP requests is processed
420
with 'ie' flags, the corresponding response must be processed
422
Note: As rtpproxy in bridge mode s per default asymmetric, you
423
have to specify the 'w' flag for clients behind NAT! See also
425
+ x - this flag a shortcut for using the "ie" or "ei"-flags of
426
RTP-Proxy, in order to do automatic bridging between IPv4 on
427
the "internal network" and IPv6 on the "external network". The
428
distinction is done by the given IP in the SDP, e.g. a IPv4
429
Address will always call "ie" to the RTPProxy (IPv4(i) to
430
IPv6(e)) and an IPv6Address will always call "ei" to the
452
+ i, e - these flags specify the direction of the SIP message.
453
These flags only make sense when rtpproxy is running in
454
bridge mode. 'i' means internal network (LAN), 'e' means
455
external network (WAN). 'i' corresponds to rtpproxy's first
456
interface, 'e' corresponds to rtpproxy's second interface.
457
You always have to specify two flags to define the incoming
458
network and the outgoing network. For example, 'ie' should be
459
used for SIP message received from the local interface and
460
sent out on the external interface, and 'ei' vice versa.
461
Other options are 'ii' and 'ee'. So, for example if a SIP
462
requests is processed with 'ie' flags, the corresponding
463
response must be processed with 'ie' flags.
464
Note: As rtpproxy in bridge mode s per default asymmetric,
465
you have to specify the 'w' flag for clients behind NAT! See
467
+ x - this flag a shortcut for using the "ie" or "ei"-flags of
468
RTP-Proxy, in order to do automatic bridging between IPv4 on
469
the "internal network" and IPv6 on the "external network".
470
The distinction is done by the given IP in the SDP, e.g. a
471
IPv4 Address will always call "ie" to the RTPProxy (IPv4(i)
472
to IPv6(e)) and an IPv6Address will always call "ei" to the
431
473
RTPProxy (IPv6(e) to IPv4(i)).
432
Note: Please note, that this will only work properly with
433
non-dual-stack user-agents or with dual-stack clients
434
according to RFC6157 (which suggest ICE for Dual-Stack
435
implementations). This short-cut will not work properly with
436
RFC4091 (ANAT) compatible clients, which suggests having
437
different m-lines with different IP-protocols grouped
474
Note: Please note, that this will only work properly with
475
non-dual-stack user-agents or with dual-stack clients
476
according to RFC6157 (which suggest ICE for Dual-Stack
477
implementations). This short-cut will not work properly with
478
RFC4091 (ANAT) compatible clients, which suggests having
479
different m-lines with different IP-protocols grouped
439
+ f - instructs rtpproxy to ignore marks inserted by another
440
rtpproxy in transit to indicate that the session is already
441
goes through another proxy. Allows creating a chain of
481
+ f - instructs rtpproxy to ignore marks inserted by another
482
rtpproxy in transit to indicate that the session is already
483
goes through another proxy. Allows creating a chain of
443
+ r - flags that IP address in SDP should be trusted. Without
444
this flag, rtpproxy ignores address in the SDP and uses source
445
address of the SIP message as media address which is passed to
447
+ o - flags that IP from the origin description (o=) should be
485
+ r - flags that IP address in SDP should be trusted. Without
486
this flag, rtpproxy ignores address in the SDP and uses
487
source address of the SIP message as media address which is
488
passed to the RTP proxy.
489
+ o - flags that IP from the origin description (o=) should be
449
+ c - flags to change the session-level SDP connection (c=) IP
491
+ c - flags to change the session-level SDP connection (c=) IP
450
492
if media-description also includes connection information.
451
+ w - flags that for the UA from which message is received,
493
+ w - flags that for the UA from which message is received,
452
494
support symmetric RTP must be forced.
453
+ zNN - requests the RTPproxy to perform re-packetization of RTP
454
traffic coming from the UA which has sent the current message
455
to increase or decrease payload size per each RTP packet
456
forwarded if possible. The NN is the target payload size in
457
ms, for the most codecs its value should be in 10ms
458
increments, however for some codecs the increment could differ
459
(e.g. 30ms for GSM or 20ms for G.723). The RTPproxy would
460
select the closest value supported by the codec. This feature
461
could be used for significantly reducing bandwith overhead for
462
low bitrate codecs, for example with G.729 going from 10ms to
463
100ms saves two thirds of the network bandwith.
495
+ zNN - requests the RTPproxy to perform re-packetization of
496
RTP traffic coming from the UA which has sent the current
497
message to increase or decrease payload size per each RTP
498
packet forwarded if possible. The NN is the target payload
499
size in ms, for the most codecs its value should be in 10ms
500
increments, however for some codecs the increment could
501
differ (e.g. 30ms for GSM or 20ms for G.723). The RTPproxy
502
would select the closest value supported by the codec. This
503
feature could be used for significantly reducing bandwith
504
overhead for low bitrate codecs, for example with G.729 going
505
from 10ms to 100ms saves two thirds of the network bandwith.
464
506
* ip_address - new SDP IP address.
466
508
This function can be used from ANY_ROUTE.
468
Example 1.10. rtpproxy_offer usage
510
Example 1.12. rtpproxy_offer usage
471
513
if (is_method("INVITE")) {
514
if (has_body("application/sdp")) {
473
515
if (rtpproxy_offer())
479
if (is_method("ACK") && has_sdp())
521
if (is_method("ACK") && has_body("application/sdp"))
480
522
rtpproxy_answer();
522
564
Meaning of the parameters is as follows:
523
565
* flags - flags to turn on some features.
524
+ 1 - append first Via branch to Call-ID when sending command to
525
rtpproxy. This can be used to create one media session per
526
branch on the rtpproxy. When sending a subsequent "delete"
527
command to the rtpproxy, you can then stop just the session
566
+ 1 - append first Via branch to Call-ID when sending command
567
to rtpproxy. This can be used to create one media session per
568
branch on the rtpproxy. When sending a subsequent "delete"
569
command to the rtpproxy, you can then stop just the session
528
570
for a specific branch when passing the flag '1' or '2' in the
529
"unforce_rtpproxy", or stop all sessions for a call when not
530
passing one of those two flags there. This is especially
531
useful if you have serially forked call scenarios where
532
rtpproxy gets an "update" command for a new branch, and then a
533
"delete" command for the previous branch, which would
534
otherwise delete the full call, breaking the subsequent
535
"lookup" for the new branch. This flag is only supported by
571
"unforce_rtpproxy", or stop all sessions for a call when not
572
passing one of those two flags there. This is especially
573
useful if you have serially forked call scenarios where
574
rtpproxy gets an "update" command for a new branch, and then
575
a "delete" command for the previous branch, which would
576
otherwise delete the full call, breaking the subsequent
577
"lookup" for the new branch. This flag is only supported by
536
578
the ngcp-mediaproxy-ng rtpproxy at the moment!
537
+ 2 - append second Via branch to Call-ID when sending command
579
+ 2 - append second Via branch to Call-ID when sending command
538
580
to rtpproxy. See flag '1' for its meaning.
539
+ b - append branch specific variable to Call-ID when sending
540
command to rtpproxy. See rtpproxy_offer() for details.
581
+ b - append branch specific variable to Call-ID when sending
582
command to rtpproxy. See rtpproxy_offer() for details.
543
t - do not include To tag to "delete" command to rtpproxy thus
544
causing full call to be deleted. Useful for deleting unused
545
rtpproxy call when 200 OK is received on a branch, where
546
rtpproxy is not needed.
585
t - do not include To tag to "delete" command to rtpproxy
586
thus causing full call to be deleted. Useful for deleting
587
unused rtpproxy call when 200 OK is received on a branch,
588
where rtpproxy is not needed.
548
Example 1.12. rtpproxy_destroy usage
590
Example 1.14. rtpproxy_destroy usage
550
592
rtpproxy_destroy();
553
5.5. unforce_rtp_proxy()
595
5.5. unforce_rtp_proxy()
555
597
Same as rtpproxy_destroy().
557
5.6. rtpproxy_manage([flags [, ip_address]])
599
5.6. rtpproxy_manage([flags [, ip_address]])
559
Manage the RTPProxy session - it combines the functionality of
560
rtpproxy_offer(), rtpproxy_answer() and unforce_rtpproxy(), detecting
601
Manage the RTPProxy session - it combines the functionality of
602
rtpproxy_offer(), rtpproxy_answer() and unforce_rtpproxy(), detecting
561
603
internally based on message type and method which one to execute.
563
It can take the same parameters as rtpproxy_offer(). The flags
564
parameter to rtpproxy_manage() can be a configuration variable
605
It can take the same parameters as rtpproxy_offer(). The flags
606
parameter to rtpproxy_manage() can be a configuration variable
565
607
containing the flags as a string.
568
610
* If INVITE with SDP, then do rtpproxy_offer()
569
611
* If INVITE with SDP, when the tm module is loaded, mark transaction
570
with internal flag FL_SDP_BODY to know that the 1xx and 2xx are for
612
with internal flag FL_SDP_BODY to know that the 1xx and 2xx are
613
for rtpproxy_answer()
572
614
* If ACK with SDP, then do rtpproxy_answer()
573
* If BYE or CANCEL, or called within a FAILURE_ROUTE[], then do
615
* If BYE or CANCEL, or called within a FAILURE_ROUTE[], then do
574
616
unforce_rtpproxy()
575
617
* If reply to INVITE with code >= 300 do unforce_rtpproxy()
576
* If reply with SDP to INVITE having code 1xx and 2xx, then do
577
rtpproxy_answer() if the request had SDP or tm is not loaded,
618
* If reply with SDP to INVITE having code 1xx and 2xx, then do
619
rtpproxy_answer() if the request had SDP or tm is not loaded,
578
620
otherwise do rtpproxy_offer()
580
622
This function can be used from ANY_ROUTE.
582
Example 1.13. rtpproxy_manage usage
624
Example 1.15. rtpproxy_manage usage
584
626
rtpproxy_manage();
587
5.7. rtpproxy_stream2uac(prompt_name, count),
629
5.7. rtpproxy_stream2uac(prompt_name, count),
589
Instruct the RTPproxy to stream prompt/announcement pre-encoded with
631
Instruct the RTPproxy to stream prompt/announcement pre-encoded with
590
632
the makeann command from the RTPproxy distribution. The uac/uas suffix
591
selects who will hear the announcement relatively to the current
633
selects who will hear the announcement relatively to the current
592
634
transaction - UAC or UAS. For example invoking the rtpproxy_stream2uac
593
in the request processing block on ACK transaction will play the prompt
594
to the UA that has generated original INVITE and ACK while
595
rtpproxy_stop_stream2uas on 183 in reply processing block will play the
596
prompt to the UA that has generated 183.
635
in the request processing block on ACK transaction will play the
636
prompt to the UA that has generated original INVITE and ACK while
637
rtpproxy_stop_stream2uas on 183 in reply processing block will play
638
the prompt to the UA that has generated 183.
598
Apart from generating announcements, another possible application of
599
this function is implementing music on hold (MOH) functionality. When
600
count is -1, the streaming will be in loop indefinitely until the
640
Apart from generating announcements, another possible application of
641
this function is implementing music on hold (MOH) functionality. When
642
count is -1, the streaming will be in loop indefinitely until the
601
643
appropriate rtpproxy_stop_stream2xxx is issued.
603
In order to work correctly, these functions require that a session in
645
In order to work correctly, these functions require that a session in
604
646
the RTPproxy already exists. Also those functions don't alter the SDP,
605
so that they are not a substitute for calling rtpproxy_offer or
647
so that they are not a substitute for calling rtpproxy_offer or
608
650
This function can be used from REQUEST_ROUTE, ONREPLY_ROUTE.
610
652
Meaning of the parameters is as follows:
611
* prompt_name - name of the prompt to stream. Should be either
612
absolute pathname or pathname relative to the directory where
653
* prompt_name - name of the prompt to stream. Should be either
654
absolute pathname or pathname relative to the directory where
614
* count - number of times the prompt should be repeated. A value of
615
-1 means that it will be streaming in a loop indefinitely, until
656
* count - number of times the prompt should be repeated. A value of
657
-1 means that it will be streaming in a loop indefinitely, until
616
658
the appropriate rtpproxy_stop_stream2xxx is issued.
618
Example 1.14. rtpproxy_stream2xxx usage
660
Example 1.16. rtpproxy_stream2xxx usage
620
662
if (is_method("INVITE")) {
621
663
rtpproxy_offer();
added
removed
modules/rtpproxy/README
