[Spce-user] Fwd: 400 Normal Release
Andreas Granig
agranig at sipwise.com
Fri Oct 19 20:25:40 EDT 2012
Hi Dave,
Well, basically you could tell these guys that they shouldn't even care
about the second Via header. The whole Via vector defines via which path
to send the replies back to the originating party, so the only
information your peer should be concerned about is the very first Via,
and there is no reason at all for them to mess with anything else. So
they're definitely violating the SIP RFC, which might help you to put
some pressure on them.
Anyways as a first step to work around their faults you should try to
configure a dummy interface ("modprobe dummy; ifconfig dummy0
192.168.255.254") and put it into config.yml.
If they also replace RFC1918 addresses, there's a final option at
http://kamailio.org/docs/modules/stable/modules/topoh.html which you'd
need to configure in the lb config, but this should be the last resort.
Andreas
On 10/20/2012 01:58 AM, Dave Massey wrote:
>
> 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
>> <mailto: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 <mailto:dave at optionsdsl.ca>>,
>> "Dan Lan" <danlan at tieus.com <mailto: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 <mailto:john.tan at tieus.com>
>>
>>
>> ----- Original Message -----
>> *From:* Dave Massey <mailto:dave at optionsdsl.ca>
>> *To:* Dan Lan <mailto:danlan at tieus.com>
>> *Cc:* John Tan <mailto:john.tan at tieus.com>
>> *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
>>> <mailto: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
>>> <mailto:jbonilla at sipwise.com>>
>>> *Cc: *spce-user at lists.sipwise.com
>>> <mailto:spce-user at lists.sipwise.com>, Dave Massey
>>> <dave at optionsdsl.ca <mailto:dave at optionsdsl.ca>>
>>>
>>> El Thu, 18 Oct 2012 18:50:30 +0200
>>> Jon Bonilla (Manwe) <jbonilla at sipwise.com
>>> <mailto: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 :)
>
>
>
> _______________________________________________
> Spce-user mailing list
> Spce-user at lists.sipwise.com
> http://lists.sipwise.com/listinfo/spce-user
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 897 bytes
Desc: OpenPGP digital signature
URL: <http://lists.sipwise.com/pipermail/spce-user_lists.sipwise.com/attachments/20121020/3faf21bb/attachment-0001.asc>
More information about the Spce-user
mailing list