[Freeswitch-dev] FreeSWITCH Nortel Gateway Interop

Benjamin Willis bwillis at teldio.com
Fri May 8 19:44:57 PDT 2009


I guess the issue was a little too in-depth for assistance.  Anyhow,  
we have resolved this issue by using maddr instead of fs_path and now  
have calls working between a FreeSWITCH and Nortel system which we  
have started to document http://wiki.freeswitch.org/wiki/ 
Connecting_Freeswitch_And_Nortel.

Ben

On May 5, 2009, at 2:51 PM, Benjamin Willis wrote:

> Greetings,
>
> We are performing interop testing to have FreeSWITCH as a gateway
> with a Nortel CS1000 box and would appreciate any help resolving our
> issues.  There is a box that is a registrar and a redirect server.
> We can successfully register against this box.  The box is picky
> about the invites we send; it expects something like the following :
>
> INVITE sip:2270;phone-context=cdp.udp at newdomain.com;user=phone SIP/2.0
>
> After great help from the freeSWITCH IRC we came up with the
> following dialplan entry to achieve this style header :
>
> <action application="bridge" data="sofia/internal/sip:$1;phone-
> context=cdp.udp at newdomain.com;user=phone;fs_path=sip:
> 192.168.15.8:5060;"/>
>
> At this point we are sending the formatted INVITE message as the
> redirect server expects.  Our next issue where we would appreciate
> help is after the INVITE is sent, the redirect server sends back a
> 302 Moved Temporarily as expected.
>
>     SIP/2.0 302 Moved Temporarily
>     Via: SIP/2.0/TCP
> 192.168.15.11;branch=z9hG4bKy0NcZvFcNr1ZB;received=192.168.15.11
>     From: "User 210" <sip:2300 at 192.168.15.11>;tag=jjmgrmHN6Qjaa
>     To: <sip:2270;phone-
> context=cdp.udp at newdomain.com;user=phone>;tag=49582
>     Call-ID: 6998551e-b04c-122c-2d80-39a48cb53b8d
>     CSeq: 114437328 INVITE
>     Contact: <sip:2270;phone-context=cdp.udp at newdomain.com:
> 5060;maddr=192.168.15.10;transport=tcp;user=phone;x-nt-
> redirect=redirect-server>
>     Content-Length: 0
>
> The subsequent INVITE message is, again, sent back to the redirect
> server, not to the machine indicated by the maddr entry in the
> Contact field.  The new INVITE looks like this :
>
> INVITE sip:2270;phone-context=cdp.udp at newdomain.com:
> 5060;maddr=192.168.15.10;transport=tcp;user=phone;x-nt-
> redirect=redirect-server SIP/2.0
> Via: SIP/2.0/UDP 192.168.15.11;rport;branch=z9hG4bK93BXjtmKD9pcN
> Route: <sip:192.168.15.8:5060>
> Max-Forwards: 69
> From: "User 210" <sip:2300 at 192.168.15.11>;tag=ppSKZmm0rpS3e
> To: <sip:2270;phone-context=cdp.udp at newdomain.com;user=phone>
> Call-ID: ce59ac9e-b058-122c-2780-39a48cb53b8d
> CSeq: 114439989 INVITE
> Contact: <sip:mod_sofia at 192.168.15.11:5060>
> User-Agent: FreeSWITCH-mod_sofia/1.0.3-12163
> Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE,
> NOTIFY, REFER, UPDATE, REGISTER, INFO, PUBLISH
> Supported: timer, precondition, path, replaces
> Allow-Events: talk, presence, dialog, call-info, sla, include-session-
> description, presence.winfo, message-summary, refer
> Content-Type: application/sdp
> Content-Disposition: session
> Content-Length: 360
> Remote-Party-ID: "User 210" <sip:
> 2300 at 192.168.15.11>;screen=yes;privacy=off
>
> v=0
> o=FreeSWITCH 6002387420083056305 1437766807142321498 IN IP4
> 192.168.15.11
> s=FreeSWITCH
> c=IN IP4 192.168.15.11
> t=0 0
> m=audio 28220 RTP/AVP 10 0 8 9 3 101 13
> a=rtpmap:10 L16/8000
> a=rtpmap:0 PCMU/8000
> a=rtpmap:8 PCMA/8000
> a=rtpmap:9 G722/8000
> a=rtpmap:3 GSM/8000
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-16
> a=rtpmap:13 CN/8000
> a=ptime:20
>
> The following is a wireshark capture of the repeated INVITE messages
> back to the same machine, it repeats 3 times after the initial  
> invite :
>
> Conv.| Time    | 192.168.15.11     | 192.168.15.8      |
> 0    |17.284   |         INVITE SDP ( 16-bit audio, stereo g711U
> g711A ...2 GSM teleph)          |SIP From: sip:2300 at 192.168.15.11
> To:sip:2270
>       |         |(5060)   ------------------>  (5060)   |
> 0    |17.291   |         302 Moved Temporarily          |SIP Status
>       |         |(5060)   <------------------  (5060)   |
> 0    |17.291   |         ACK       |                   |SIP Request
>       |         |(5060)   ------------------>  (5060)   |
> ---------------------------------------------------------
> 1    |17.291   |         INVITE SDP ( 16-bit audio, stereo g711U
> g711A ...2 GSM teleph)          |SIP From: sip:2300 at 192.168.15.11
> To:sip:2270
>       |         |(5060)   ------------------>  (5060)   |
> 1    |17.298   |         302 Moved Temporarily          |SIP Status
>       |         |(5060)   <------------------  (5060)   |
> 1    |17.298   |         ACK       |                   |SIP Request
>       |         |(5060)   ------------------>  (5060)   |
> ---------------------------------------------------------
> 2    |17.298   |         INVITE SDP ( 16-bit audio, stereo g711U
> g711A ...2 GSM teleph)          |SIP From: sip:2300 at 192.168.15.11
> To:sip:2270
>       |         |(5060)   ------------------>  (5060)   |
> 2    |17.304   |         302 Moved Temporarily          |SIP Status
>       |         |(5060)   <------------------  (5060)   |
> 2    |17.305   |         ACK       |                   |SIP Request
>       |         |(5060)   ------------------>  (5060)   |
> ---------------------------------------------------------
> 3    |17.305   |         INVITE SDP ( 16-bit audio, stereo g711U
> g711A ...2 GSM teleph)          |SIP From: sip:2300 at 192.168.15.11
> To:sip:2270
>       |         |(5060)   ------------------>  (5060)   |
> 3    |17.311   |         302 Moved Temporarily          |SIP Status
>       |         |(5060)   <------------------  (5060)   |
> 3    |17.311   |         ACK       |                   |SIP Request
>       |         |(5060)   ------------------>  (5060)   |
>
> At this point we are a little stuck.  We feel that the use of fs_path
> may be having unwanted effects on our redirects after looking at
> sofia_glue.c:sofia_glue_do_invite() and the parsing of the fs_path
> variable.  We haven't filed this as a bug as it may be intended
> functionality and would like to get some insight from the more
> experience members before going down such a path.
>
> Thanks in advance.
>
>
> _______________________________________________
> Freeswitch-dev mailing list
> Freeswitch-dev at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> http://www.freeswitch.org




More information about the Freeswitch-dev mailing list