503 reply goes to? help

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

503 reply goes to? help

Brett Nemeroff
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).. and they ignore the request, so I retransmit it 4-5 times.. 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. 

During the transaction, other requests replies seem to work:

 60.793458  62.25.18.34 -> 75.82.100.5  SIP/SDP Request: INVITE [hidden email];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 [hidden email], 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@202.152.59.3:5060

 60.905058  75.82.100.5 -> 202.152.59.3 SIP Request: PRACK 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 [hidden email]

 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 [hidden email];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
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: 503 reply goes to? help

Bogdan-Andrei Iancu
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@75.82.100.5
> <mailto:sip%3A5216161079999@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@202.152.59.3
> <mailto:sip%3A5216161079999@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@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@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@202.152.59.3 <mailto:sip%3A5216161079999@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@75.82.100.5
> <mailto:sip%3A5216161070241@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
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>  


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: 503 reply goes to? help

Brett Nemeroff
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 <[hidden email]> 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 [hidden email] <mailto:[hidden email]>;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 [hidden email] <mailto:[hidden email]>, 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@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@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 [hidden email] <mailto:[hidden email]>


 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 [hidden email] <mailto:[hidden email]>;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
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
 



_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: 503 reply goes to? help

Bogdan-Andrei Iancu
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
> <[hidden email] <mailto:[hidden email]>> 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@75.82.100.5
>         <mailto:sip%3A5216161079999@75.82.100.5>
>         <mailto:sip%3A5216161079999@75.82.100.5
>         <mailto:sip%253A5216161079999@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@202.152.59.3
>         <mailto:sip%3A5216161079999@202.152.59.3>
>         <mailto:sip%3A5216161079999@202.152.59.3
>         <mailto:sip%253A5216161079999@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@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@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@202.152.59.3
>         <mailto:sip%3A5216161079999@202.152.59.3>
>         <mailto:sip%3A5216161079999@202.152.59.3
>         <mailto:sip%253A5216161079999@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@75.82.100.5
>         <mailto:sip%3A5216161070241@75.82.100.5>
>         <mailto:sip%3A5216161070241@75.82.100.5
>         <mailto:sip%253A5216161070241@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
>         [hidden email] <mailto:[hidden email]>
>         http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>          
>
>
>


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: 503 reply goes to? help

Brett Nemeroff
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 <[hidden email]> 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 <[hidden email] <mailto:[hidden email]>> 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 [hidden email]
       <mailto:[hidden email]>
       <mailto:[hidden email]
       <mailto:[hidden email]>>;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 [hidden email]
       <mailto:[hidden email]>
       <mailto:[hidden email]
       <mailto:[hidden email]>>, 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@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@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
       [hidden email]
       <mailto:[hidden email]>
       <mailto:[hidden email]
       <mailto:[hidden email]>>



        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
       [hidden email]
       <mailto:[hidden email]>
       <mailto:[hidden email]
       <mailto:[hidden email]>>;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
       [hidden email] <mailto:[hidden email]>



_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: 503 reply goes to? help

Bogdan-Andrei Iancu
According to RFC 3261, the defining elements for a dialog are Callid,
To-tag and From-tag. TO-uri and From-uri are obsolete .

Regards,
Bogdan

Brett Nemeroff wrote:

> 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
> <[hidden email] <mailto:[hidden email]>> 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
>         <[hidden email] <mailto:[hidden email]>
>         <mailto:[hidden email]
>         <mailto:[hidden email]>>> 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@75.82.100.5
>         <mailto:sip%3A5216161079999@75.82.100.5>
>                <mailto:sip%3A5216161079999@75.82.100.5
>         <mailto:sip%253A5216161079999@75.82.100.5>>
>                <mailto:sip%3A5216161079999@75.82.100.5
>         <mailto:sip%253A5216161079999@75.82.100.5>
>                <mailto:sip%253A5216161079999@75.82.100.5
>         <mailto:sip%25253A5216161079999@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@202.152.59.3
>         <mailto:sip%3A5216161079999@202.152.59.3>
>                <mailto:sip%3A5216161079999@202.152.59.3
>         <mailto:sip%253A5216161079999@202.152.59.3>>
>                <mailto:sip%3A5216161079999@202.152.59.3
>         <mailto:sip%253A5216161079999@202.152.59.3>
>                <mailto:sip%253A5216161079999@202.152.59.3
>         <mailto:sip%25253A5216161079999@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@202.152.59.3:5060
>         <http://sip:5216161079999@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@202.152.59.3:5060
>         <http://sip:5216161079999@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@202.152.59.3
>         <mailto:sip%3A5216161079999@202.152.59.3>
>                <mailto:sip%3A5216161079999@202.152.59.3
>         <mailto:sip%253A5216161079999@202.152.59.3>>
>                <mailto:sip%3A5216161079999@202.152.59.3
>         <mailto:sip%253A5216161079999@202.152.59.3>
>                <mailto:sip%253A5216161079999@202.152.59.3
>         <mailto:sip%25253A5216161079999@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@75.82.100.5
>         <mailto:sip%3A5216161070241@75.82.100.5>
>                <mailto:sip%3A5216161070241@75.82.100.5
>         <mailto:sip%253A5216161070241@75.82.100.5>>
>                <mailto:sip%3A5216161070241@75.82.100.5
>         <mailto:sip%253A5216161070241@75.82.100.5>
>                <mailto:sip%253A5216161070241@75.82.100.5
>         <mailto:sip%25253A5216161070241@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
>                [hidden email]
>         <mailto:[hidden email]>
>         <mailto:[hidden email]
>         <mailto:[hidden email]>>
>
>                http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>                
>
>
>
>


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users