[OpenSIPS-Users] 503 reply goes to? help

Brett Nemeroff brett at nemeroff.com
Thu Feb 12 08:57:05 CET 2009


I was a little confused. I was trying to explain to the operator that the
reply doesn't have a RURI and that I send it with the same To/From headers
they send me.
I did check the headers and they are they same.. I'm going to be doing some
more testing on this tomorrow. It's my understanding that they should be
matching dialogs based on the to_tag and the callid, isn't that right? And
in general, I shouldn't mess with the to/from headers, right?

-Brett


On Thu, Feb 12, 2009 at 1:52 AM, Bogdan-Andrei Iancu <bogdan at voice-system.ro
> wrote:

> Hi Brett,
>
> Ok, more clear now :)
>
> " ...because the "To:" field doesn't match the RURI."
>
> I guess they refer at RURI from IINVITE request and TO hdr from reply ? If
> so, Both this entities are generated by UAC. The TO hdr from reply is the TO
> header from INVITE (plus the TO tag).
>
> So, can you visually check if the To tag (as uri) from INVITE is the same
> as in the 503 reply you sent ?
>
> Regards,
> Bogdan
>
>
> Brett Nemeroff wrote:
>
>> Ugh! I didn't make that easy, did I.. Yes, in failure route I t_reply (not
>> relay) with a 503. They ignore the REPLY, there is no new branch. The UAC is
>> ignoring my REPLY and the operator of that device is telling me that it's
>> because the "To:" field doesn't match the RURI.
>>
>> On Thu, Feb 12, 2009 at 1:26 AM, Bogdan-Andrei Iancu <
>> bogdan at voice-system.ro <mailto:bogdan at voice-system.ro>> wrote:
>>
>>    Hi Brett,
>>
>>
>>    Brett Nemeroff wrote:
>>
>>        All,
>>        I'm having an issue with a customer's nextone sbc. They send a
>>        call out, I send it to my upstream. My upstream is broken
>>        (separate issue althogether). They send me 183..183.. 500.
>>        When I get the 500, I send a 503 to the originator of the
>>        request (my customer)
>>
>>    So, in failure_route you replace the received 500 with a 503
>>    reply, right?
>>
>>
>>        .. and they ignore the request, so I retransmit it 4-5 times..
>>
>>    request? you said you already received the reply....I guess you
>>    retransmit the reply ? ..or maybe I'm missing something.
>>
>>        I'm not doing anything weird. I'm using t_relay for the 503 in
>>        a failure route and I'm not rewriting anything other than the
>>        original request ruri. No funny business with tags.
>>
>>    you mean t_reply() ? I see no new branch in the flow you post.
>>
>>    What the pseudo-trace shows is the UAC not accepting the 503 from
>>    your side, is this the issue?
>>
>>    Regards,
>>    Bogdan
>>
>>
>>        During the transaction, other requests replies seem to work:
>>
>>         60.793458  62.25.18.34 -> 75.82.100.5  SIP/SDP Request:
>>        INVITE sip:5216161079999 at 75.82.100.5<sip%3A5216161079999 at 75.82.100.5>
>>        <mailto:sip%3A5216161079999 at 75.82.100.5<sip%253A5216161079999 at 75.82.100.5>
>> >
>>        <mailto:sip%3A5216161079999 at 75.82.100.5<sip%253A5216161079999 at 75.82.100.5>
>>        <mailto:sip%253A5216161079999 at 75.82.100.5<sip%25253A5216161079999 at 75.82.100.5>>>;user=phone,
>> with
>>        session description
>>
>>
>>         60.796605  75.82.100.5 -> 62.25.18.34  SIP Status: 100 Giving
>>        a try
>>
>>         60.796847  75.82.100.5 -> 202.152.59.3 SIP/SDP Request:
>>        INVITE sip:5216161079999 at 202.152.59.3<sip%3A5216161079999 at 202.152.59.3>
>>        <mailto:sip%3A5216161079999 at 202.152.59.3<sip%253A5216161079999 at 202.152.59.3>
>> >
>>        <mailto:sip%3A5216161079999 at 202.152.59.3<sip%253A5216161079999 at 202.152.59.3>
>>        <mailto:sip%253A5216161079999 at 202.152.59.3<sip%25253A5216161079999 at 202.152.59.3>>>,
>> with session
>>        description
>>
>>
>>         60.822516 202.152.59.3 -> 75.82.100.5  SIP Status: 100 Trying
>>
>>         60.891115 202.152.59.3 -> 75.82.100.5  SIP/SDP Status: 183
>>        Session Progress, with session description
>>
>>         60.892837  75.82.100.5 -> 62.25.18.34  SIP/SDP Status: 183
>>        Session Progress, with session description
>>
>>         60.903312  62.25.18.34 -> 75.82.100.5  SIP Request: PRACK
>>        sip:5216161079999 at 202.152.59.3:5060
>>        <http://sip:5216161079999@202.152.59.3:5060>
>>        <http://sip:5216161079999@202.152.59.3:5060>
>>
>>         60.905058  75.82.100.5 -> 202.152.59.3 SIP Request: PRACK
>>        sip:5216161079999 at 202.152.59.3:5060
>>        <http://sip:5216161079999@202.152.59.3:5060>
>>        <http://sip:5216161079999@202.152.59.3:5060>
>>
>>
>>         60.919007 202.152.59.3 -> 75.82.100.5  SIP Status: 200 OK
>>
>>         60.919730  75.82.100.5 -> 62.25.18.34  SIP Status: 200 OK
>>
>>         66.324643 202.152.59.3 -> 75.82.100.5  SIP Status: 500
>>        Internal Server Error
>>
>>         66.325256  75.82.100.5 -> 202.152.59.3 SIP Request: ACK
>>        sip:5216161079999 at 202.152.59.3 <sip%3A5216161079999 at 202.152.59.3>
>>        <mailto:sip%3A5216161079999 at 202.152.59.3<sip%253A5216161079999 at 202.152.59.3>
>> >
>>        <mailto:sip%3A5216161079999 at 202.152.59.3<sip%253A5216161079999 at 202.152.59.3>
>>        <mailto:sip%253A5216161079999 at 202.152.59.3<sip%25253A5216161079999 at 202.152.59.3>
>> >>
>>
>>
>>         66.326427  75.82.100.5 -> 62.25.18.34  SIP Status: 503
>>        Service Unavailable
>>
>>         66.796377  75.82.100.5 -> 62.25.18.34  SIP Status: 503
>>        Service Unavailable
>>
>>         67.797229  75.82.100.5 -> 62.25.18.34  SIP Status: 503
>>        Service Unavailable
>>
>>         69.798014  75.82.100.5 -> 62.25.18.34  SIP Status: 503
>>        Service Unavailable
>>
>>         74.689429  62.25.18.34 -> 75.82.100.5  SIP Request: CANCEL
>>        sip:5216161070241 at 75.82.100.5 <sip%3A5216161070241 at 75.82.100.5>
>>        <mailto:sip%3A5216161070241 at 75.82.100.5<sip%253A5216161070241 at 75.82.100.5>
>> >
>>        <mailto:sip%3A5216161070241 at 75.82.100.5<sip%253A5216161070241 at 75.82.100.5>
>>        <mailto:sip%253A5216161070241 at 75.82.100.5<sip%25253A5216161070241 at 75.82.100.5>
>> >>;user=phone
>>
>>
>>         74.690889  75.82.100.5 -> 62.25.18.34  SIP Status: 200 canceling
>>
>>
>>        See, that 503 at the bottom doesn't make it through..
>>        Another bit of information. The "To:" header contains a prefix
>>        to the RURI. I don't care, I ignore the to header.. The 503
>>        reply ALSO has the To Header. The customer, is telling me that
>>        the To: header in the 503 reply  needs to match the RURI. I
>>        believe that I shouldn't ever touch the To: or From: headers
>>        and that they should match exactly what he sent me.
>>
>>
>>        Any ideas what's going on here? Am I off base?
>>
>>
>>
>>  ------------------------------------------------------------------------
>>
>>
>>
>>        _______________________________________________
>>        Users mailing list
>>        Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>>        http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opensips.org/pipermail/users/attachments/20090212/cfebd187/attachment-0001.htm 


More information about the Users mailing list