[SR-Users] How to connect two legs of a call

Chester Wood chet at dewachen.org
Thu Mar 15 03:22:54 CET 2012


Thanks so much for the reply. It seems the implementation per your
suggestion could be much simpler than what I was thinking ---
branching the request, etc. But it seems the SIP traffic doesn't need
to be modified at all --- the only thing that needs to be done is swap
out the SDP payload at the appropriate point.

Alas, there are other problems. Provider A (my preferred provider)
does retain the Call-ID across the two sides of the call. But they
lock down the configuration of the ATA so that I don't have access to
set an outbound proxy. So while we're negotiating with them for access
to this setting (and thinking about ways to spoof DNS to get around
it), I'm experimenting with Provider B, which allows outbound proxy.
But Provider B changes the Call-ID and seemingly everything else
across the two legs of the call, so I can't find any data in common
with which to match the legs of the call. I'm using the Kamailio
default config (v1.5) with some extra accounting fields and I get this
for the incoming leg:

ACC: transaction answered:
timestamp=1331754737;method=INVITE;from_tag=as16a2c924;to_tag=D87010CFF36BFA5657588EA128406A52;call_id=3946248821802e263dddeb0c34e665d9 at 140.239.143.5;code=200;reason=OK;fm_uri=sip:9999999999 at 140.239.143.5;to_uri=sip:chet_stone at 192.168.1.138:4785;rinstance=A07E0129;ruri=sip:chet_stone at 192.168.1.138:4785;rinstance=A07E0129;dst_uri=;o_uri=sip:chet_stone at 192.168.1.138:4785;rinstance=A07E0129;src_ip=140.239.143.5;cntct=<sip:9999999999 at 140.239.143.5>

And this for the outgoing:

ACC: transaction answered:
timestamp=1331754737;method=INVITE;from_tag=SP23596c1df25965e82;to_tag=as1a190307;call_id=b0040f33 at 192.168.1.200;code=200;reason=OK;fm_uri=sip:chet_xtra at sip16.vitelity.net;to_uri=sip:17195307999 at sip16.vitelity.net;ruri=sip:17195307999 at sip16.vitelity.net:5060;dst_uri=;o_uri=sip:17195307999 at sip16.vitelity.net:5060;src_ip=192.168.1.200;cntct=<sip:chet_xtra at 192.168.1.200:5061>



It seems like any solution to this may not be very robust because the
provider could change the configuration of their B2BUA at any time.
Perhaps I could pass the original ID or the entire SDP info in a special header.

thanks again for the help.

chester

>> IP address scarcity we have to use large scale NAT in our network. In
>> order for our local customers to call each other and have good call
>> quality we wish to connect their ATA's directly to each other rather
>> than have the RTP proxied 6000 miles across the public internet.
>>
>> I'm wondering about the best way to program an outbound proxy to
>> monitor the calls and bypass the ITSP's B2BUA for local calls. We want
>> to rely on the ITSP's server for authentication (so we would only
>> REGISTER our UA's locally after we get an OK from the remote
>> server. Or perhaps we would not need a local registrar at all.)
>>
>> The remote server is also where the users manage their account. So we
>> only want to attempt to connect the 2 UA's directly after the callee
>> has sent an "OK" response to the INVITE from the ITSP. (The callee may
>> have set "Do not disturb" on his account at the ITSP, and it needs to
>> handle voicemail, forwarding etc.)
>>
>> We have other constraints. The server hardware needs to be very low
>> power to be installed at our solar-powered head end. Thus for
>> potentially several hundred clients it needs to handle only SIP, no
>> media. We could potentially install a media relay server elsewhere,
>> but hopefully we won't need to do any media proxying at all.
>>
>> The NAT assignment is all handled by a Mikrotik router at our head
>> end.  I've looked at the milkfish configuration file and it seems like
>> in some ways, ours should be simpler. Milkfish assumes it is running
>> on the gateway, so when it sets up an rtpproxy it doesn't cost
>> anything. For us, it doesn't seem like we should have to do any NAT
>> fixup or any media proxying. If the connection is local, the 2 UA's
>> should connect directly with each other. Otherwise, the connection
>> will be directly between our UA and whatever the ITSP sets up as the
>> other end, and the ITSP already knows how to traverse our NAT very
>> well.
>>
>>
>> One idea I had is that, for local calls, when the initial INVITE is
>> forwarded from the caller to the ITSP, the caller's original SDP
>> payload is stashed away somewhere.  Then when the INVITE comes through
>> on the way to the callee, replace the ITSP's SDP info with the stashed
>> original.  Then when the callee responds with an "OK", I forward the
>> response directly to the caller instead of the ITSP.
>>
>> There would have to be some fixup of loose ends, also. How to let the
>> ITSP that its proxy services are no longer needed? (It could have
>> decided to forward the call to voicemail in the meantime, etc.)
>>
>> Can you query the SER transaction database by Call-ID to find the
>> other side of the call and extract information from it?
>>
>> Perhaps I'm barking up the wrong tree, but I'm sure there's a correct
>> way to do this.
>>
>> Any help would be appreciated.
>
>
> what you can try is to use htable module to store in memory the sdp based on
> caller/callee or call-id (if preserved by provider when returning the
> invite/200ok). Then use textops module to set the body with the sdp taken
> from htable.
>
> Cheers,
> Daniel
>
>
>
> --
> Daniel-Constantin Mierla
>   http://www.asipto.com



More information about the sr-users mailing list