[Spce-user] Fwd: 400 Normal Release

Dave Massey dave at optionsdsl.ca
Fri Oct 19 20:30:17 EDT 2012 

Ok I will pass it on, but Im definitely not going to get my hopes up. :(

Ive got issues with the dummy module inside the openVZ container, that I have to figure out how to get done, Ive tried using eth0:0  and lo:0 but neither work (ATAs wont register anymore (even using 192.168.x.x) )


On 2012-10-19, at 8:25 PM, Andreas Granig <agranig at sipwise.com> wrote:

> 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
>> 
> 
> _______________________________________________
> Spce-user mailing list
> Spce-user at lists.sipwise.com
> http://lists.sipwise.com/listinfo/spce-user

More information about the Spce-user mailing list