Hi Andreas,
I was doing something remotely similar in the past. My approach to your
case would roughly be the following:
- use one |<ereg>| per payload type number position in the |m=| line to
extract the payload type numbers into dedicated variables, something like
|<recv request="INVITE">||
|| <action>||
|| <ereg regexp="m=audio +[0-9]+ +RTP/AVP +([0-9]+) +"
search_in="msg" assign_to="dummy,codec_1"/>||
|| <ereg regexp="m=audio +[0-9]+ +RTP/AVP +[0-9]+ +([0-9]+) +"
search_in="msg" assign_to="dummy,codec_2"/>||
|| <ereg regexp="m=audio +[0-9]+ +RTP/AVP +([0-9]+ +){2}([0-9]+) +"
search_in="msg" assign_to="dummy,dummy_2,codec_3"/>||
|| <ereg regexp="m=audio +[0-9]+ +RTP/AVP +([0-9]+ +){3}([0-9]+) +"
search_in="msg" assign_to="dummy,dummy_2,codec_4"/>||
|| ...||
|| </action>||
||</recv>||
|
||
- use conditional commands to compose the SDP answer in a variable,
first appending the payload type numbers to the end of the |m=| line and
then appending the |a=rtpmap| lines for that codec, something like
<nop>
<action>
<assignstr assign_to="m_line" value="m=audio [media_port] RTP/AVP [$codec_1]"
/>
</action>
</nop>
<nop condexec="codec_2">
<action>
<assignstr assign_to="m_line" value="[$m_line] [$codec_2]" />
</action>
</nop>
<nop condexec="codec_3">
<action>
<assignstr assign_to="m_line" value="[$m_line] [$codec_3]" />
</action>
</nop>
...
Next, you need to search through your composed |m=| line, and provide
the appropriate |a=| lines for each known payload type number, something
like
|<nop>||
|| <action>||
|| <assignstr assign_to="a_lines" value=""/>||
||| <ereg search_in="var" variable="m_line" regexp=" 0[ $]"
assign_to="is_pcmu"||
||| <ereg search_in="var" variable="m_line" regexp=" 8[ $]"
assign_to="is_pcma"
|| <ereg search_in="var" variable="m_line" regexp=" 101[ $]"
assign_to="is_g729"||||
|| </action>||
||</nop>
|
||<nop condexec="is_pcmu">||
|| <action>||
|| <assignstr assign_to="a_lines" value="[$a_lines]a=rtpmap:0
PCMU/8000\x0d\x0a"/>||
||</action>||
||</nop>
||
||||<nop condexec="is_pcma">||
|| <action>||
|| <assignstr assign_to="a_lines" value="[$a_lines]a=rtpmap:8
PCMA/8000\x0d\x0a"/>||
||</action>||
||</nop>
||||
||||||<nop condexec="is_g729">||
|| <action>||
|| <assignstr assign_to="a_lines" value="[$a_lines]a=rtpmap:18
G729/8000\x0d\x0aa=fmtp:18 annexb=no\x0d\x0a"/>||
||</action>||
||</nop>
|||| |||| ||||
The above should work but does not take into account dynamic payload
types (and even payload type numbers below 96 can be used for dynamic
assignment).
Bear in mind that the variable |[$a_lines]| has a line break at its end
unless it is completely empty, so the next line of your SDP must follow
it directly:
|v=0||
||o=ccs-0-275-2 02722940331338705 331338705 IN IP[local_ip_type]
[local_ip]||
||s=SIP Call||
||c=IN IP[media_ip_type] [media_ip]||
||t=0 0||
||[$m_line]||
||[$a_lines]||a=sendrecv||
|
Happy debugging, I haven't tested anything. Remarks:
- if the |"[ $]"| construct does not work in regexp matching against a
variable, you may have to compose the |m=| line with a space in the end
first, then parse it for known codecs with plain |" "| instead of the
|"[ $]"|, and finally trim the last |" "|.
- it is possible that |\r\n| can be used instead of |\x0d\x0a|.
- if you want to silently drop unexpected payload type numbers, you have
to change the regexps parsing the received |m=| line, replace the last
|([0-9]+)| by a |-separated list of known payload type numbers, such as
|(0|8|18|101)|. Doing so adds complexity as you have to handle the
possibility of ending up with empty |[$a_lines]| (which you have to test
for and append |"\x0d\x0a"| if it happens) and if you want to test
things like codec order in SDP answer different from the one in the SDP
offer.
Pavel
Dne 13.11.2017 v 2:21 Andreas Byström (Polystar) napsal(a):
Hi
Has someone ever created a UAS script that respond with the same
codec(s) as the incoming INVITE SDP offer?
The scripts I have used I usually create the 200 OK using something
like this:
<!-- Send 200 OK on UPDATE -->
<send>
<![CDATA[
SIP/2.0 200 OK
[last_Via:]
[last_From:]
[last_To:]
[last_Call-ID:]
[last_CSeq:]
Contact: <sip:test@[local_ip]:[local_port];transport=[transport] >
Content-Type: application/sdp
Content-Length: [len]
v=0 0
o=ccs-0-275-2 02722940331338705 331338705 IN IP[local_ip_type]
[local_ip]
s=-
c=IN IP[media_ip_type] [media_ip]
t=0 0
m=audio [media_port] RTP/AVP 8
a=ptime:20
But the above SDP in the 200 OK assumes that the incoming INVITE has
an SDP with g711alaw/PCMA (payloadtype=8) as offered codec. If the
incoming call had for example AMR, the call will fail if UAS responds
with above.
Everytime I change codec in phone that places the call to this UAS, I
need to manually update the UAS script with the correct payload type
and sometimes with a=rtpmap / fmtp lines
My question is if there is a way to have the UAS use the same as the
incoming SDP? The script needs their own [media_port] so it cannot
copy the m= line fully. It needs to copy only the characters after
RTP/AVP from that line. Also, it need to copy all lines that starts
with a=rtpmap or a=fmtp since they can have information about the
codec choosen. I’m happy if there is a way to support one codec option
(i.e one payloadtype after RTP/AVP and possible one rtpmap and/or one
fmtp line), and its even better if it can support an unlimited number
of payload types and rtpmap/fmtp
So, does anyone have that kind of UAS and are willing to share?
Regards,
// Andreas
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users
