[Spce-user] Fwd: 400 Normal Release

Dave Massey dave at optionsdsl.ca
Fri Oct 19 19:58:02 EDT 2012


Hey This is the response I got from the peer Im having trouble with.  the first image is someone else and has nothing to do with me, and the 2nd image is me for sure.
This is gonna be a bit of a battle of " no, your end is broken!..  No YOURS is!!  "   :(

Begin forwarded message:

> From: "John Tan\(TieUs Technology Corp.\)" <john.tan at tieus.com>
> Subject: Re: [Spce-user] 400 Normal Release
> Date: 19 October, 2012 7:24:38 PM EDT
> To: "Dave Massey" <dave at optionsdsl.ca>, "Dan Lan" <danlan at tieus.com>
> 
> Hi Dave :
>  
> From our side, we check the packet between our proxy and your server. It looks your server has some parameter might need re-configure.
>  
> Usually our proxy will receive the SIP/SDP request from other party. The SIP/SDP include some network information to tell our system where to send back this request(you may find the Via info show as below).
>  
> 
>  
> However, from your server, there are two Via info in the SIP/SDP packet(show as below). The first one shows the IP 24.102.50.52 is correct but the second one shows 127.0.0.1 make our server confuse.
>  
> 
>  
> This information may cause by the parameter you set in your SIP server. There might be some option you may choice that server is connect to the Internet directly or behind the Router. Check that setting may solve this problem.
>  
> Best Regards,
>  
> John Tan 10/19/2012
> System Engineer
> TieUs Technology Corporation
> #1200 1200 West 73rd Ave.
> Vancouver  B.C. V6P 6G5
> Tel : 1-604-6060668, 1-250-4833040, 1-416-6468200, 1-403-4563788, 1-780-3287306, 1-866-9060668 EXT108
> Fax : 1-604-6380818, 1-877-8388227
> john.tan at tieus.com
>  
> ----- Original Message -----
> From: Dave Massey
> To: Dan Lan
> Cc: John Tan
> Sent: Friday, October 19, 2012 12:13 PM
> Subject: Fwd: [Spce-user] 400 Normal Release
> 
> 
> Hey guys its Dave, I have been vigorously troubleshooting the disconnect after 10 seconds issue with the developers of SPCE softswitch  and sems. 
> They came up with the following below, regarding an IP address substitution.  Im not sure if you guys can fix it? 
> Im not an expert in SIP.
> 
> 
> Begin forwarded message:
> 
>> From: Jon Bonilla (Manwe) <jbonilla at sipwise.com>
>> Subject: Re: [Spce-user] 400 Normal Release
>> Date: 19 October, 2012 10:23:58 AM EDT
>> To: Jon Bonilla (Manwe) <jbonilla at sipwise.com>
>> Cc: spce-user at lists.sipwise.com, Dave Massey <dave at optionsdsl.ca>
>> 
>> El Thu, 18 Oct 2012 18:50:30 +0200
>> Jon Bonilla (Manwe) <jbonilla at sipwise.com> escribió:
>> 
>>> I'm sorry but looks like the error comes from sems somehow. We'll need the
>>> ngrep including the communication between the proxy and sems and the sems log
>>> with debug enabled.
>>> 
>>> sems-stats -c "set_loglevel 3"
>>> ngrep-sip b port 5060 or port 5062 or port 5080 -q
>>> 
>> 
>> Ok. Thanks for the logs and thaks to sems developers (Frafos GbmH) and Andrew
>> Pogrebennyk for taking a look to the logs. It was easier than expected but I
>> didn't see it (shame on me!)
>> 
>> The invite we send to the peer is as follows:
>> 
>> U 2012/10/18 12:55:34.746152 SPCE_IP:5060 -> PEER_IP:5060
>> 
>> INVITE sip:19057722572 at PEER_IP:5060;transport=udp SIP/2.0'
>> Record-Route:
>> <sip:SPCE_IP;r2=on;lr=on;ftag=4BA41CEB-50803486000B6042-82053700;ngcplb=yes>'
>> 
>> Record-Route:
>> <sip:127.0.0.1;r2=on;lr=on;ftag=4BA41CEB-50803486000B6042-82053700;ngcplb=yes>'
>> 
>> 
>> And the 183 we get back from the peer is like this one:
>> 
>> U 2012/10/18 12:55:36.555972 PEER_IP:5060 -> SPCE_IP:5060
>> SIP/2.0 183 Session Progress'
>> 
>> Record-Route:
>> <sip:SPCE_IP;r2=on;lr=on;ftag=4BA41CEB-50803486000B6042-82053700;ngcplb=yes>'
>> 
>> Record-Route:
>> <sip:PEER_IP:5060;r2=on;lr=on;ftag=4BA41CEB-50803486000B6042-82053700;ngcplb=yes>'
>> 
>> 
>> 
>> It looks like the peer is substituting it's own IP address
>> PEER_IP:5060 where 127.0.0.1:5060 should be sent in the record-router header.
>> Due to that, sems can't route the ACK back when the call is answered and the
>> peer releases the call with a 400 (This is also something I've never seen
>> before) response. 
>> 
>> We've seen this behaviour in some Audiocodes gateways before and that a wrong
>> behavious from your peer server.
>> 
>> You have two choices: Report the behaviour to your peer and expect them to
>> solve their bad behaviour or you can change the internal ip address of you
>> sip:provider from 127.0.0.1 to something else (networking.iaddress in
>> config.yml) to something else. Create a dummy interface with some private ip
>> address and set that parameter to that value. I would do both :)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sipwise.com/mailman/private/spce-user_lists.sipwise.com/attachments/20121019/65e1292a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sipvia-1a.jpg
Type: image/jpeg
Size: 63395 bytes
Desc: not available
URL: <http://lists.sipwise.com/mailman/private/spce-user_lists.sipwise.com/attachments/20121019/65e1292a/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sipvia-2a.jpg
Type: image/jpeg
Size: 70108 bytes
Desc: not available
URL: <http://lists.sipwise.com/mailman/private/spce-user_lists.sipwise.com/attachments/20121019/65e1292a/attachment-0001.jpg>


More information about the Spce-user mailing list