Re: [Sip-implementors] Wrong SIP scheme and/or URI transport param

2011-06-09 Thread Iñaki Baz Castillo
2011/6/9 Paul Kyzivat pkyzi...@cisco.com: On 6/8/2011 3:50 PM, Iñaki Baz Castillo wrote: Some existing proxies reply some custom 4XX codes for these kind of errors. I would like some specific and standarized 4XX response code, something like:   467 Unsupported Transport Go for it! Submit

Re: [Sip-implementors] Wrong SIP scheme and/or URI transport param

2011-06-09 Thread Paul Kyzivat
On 6/9/2011 4:08 AM, Iñaki Baz Castillo wrote: 2011/6/9 Paul Kyzivatpkyzi...@cisco.com: On 6/8/2011 3:50 PM, Iñaki Baz Castillo wrote: Some existing proxies reply some custom 4XX codes for these kind of errors. I would like some specific and standarized 4XX response code, something like:

Re: [Sip-implementors] Wrong SIP scheme and/or URI transport param

2011-06-09 Thread Iñaki Baz Castillo
2011/6/9 Paul Kyzivat pkyzi...@cisco.com: For an unsupported/unrecognized transport, like sctp, 501 might be a reasonable choice. It would be a good alternative usage of 501, I agree. It would be much better than 500 for that case. 500 could be used if its a *server* problem that you

Re: [Sip-implementors] About CANCEL in a proxy (no changes to server/client transaction)

2011-06-09 Thread Iñaki Baz Castillo
2011/5/11 Bob Penfield bpenfi...@acmepacket.com: You have it correct. The proxy's job is to pass the CANCEL on each branch of the matching transaction. The basic rule of SIP is that all transactions complete independently. The state of the transactions is dependant only on the response(s)

Re: [Sip-implementors] About CANCEL in a proxy (no changes to server/client transaction)

2011-06-09 Thread Bob Penfield
The requirement for having received a 1xx response does apply to transaction stateful proxies. If the proxy does not wait, you have the same issue as you have with the UA in that the CANCEL could potentially arrive at a downstream proxy or the UAS before the INVITE. cheers, (-:bob

Re: [Sip-implementors] About CANCEL in a proxy (no changes to server/client transaction)

2011-06-09 Thread Brez Borland
On Thu, Jun 9, 2011 at 10:32 PM, Iñaki Baz Castillo i...@aliax.net wrote: 2011/5/11 Bob Penfield bpenfi...@acmepacket.com: You have it correct. The proxy's job is to pass the CANCEL on each branch of the matching transaction. The basic rule of SIP is that all transactions complete

Re: [Sip-implementors] About CANCEL in a proxy (no changes to server/client transaction)

2011-06-09 Thread Iñaki Baz Castillo
2011/6/9 Bob Penfield bpenfi...@acmepacket.com: The requirement for having received a 1xx response does apply to transaction stateful proxies. If the proxy does not wait, you have the same issue as you have with the UA in that the CANCEL could potentially arrive at a downstream proxy or the

Re: [Sip-implementors] About CANCEL in a proxy (no changes to server/client transaction)

2011-06-09 Thread Iñaki Baz Castillo
2011/6/10 Iñaki Baz Castillo i...@aliax.net: - Alice calls Bob through a proxy. - Proxy sends the INVITE to Bob and replies 100 to Alice. - Proxy gets no provisional response fmo Bob. - Alice sends CANCEL after a while. - Proxy replies 200 for CANCEL. - Proxy doesn't send CANCEL to Bob as

Re: [Sip-implementors] About CANCEL in a proxy (no changes to server/client transaction)

2011-06-09 Thread Iñaki Baz Castillo
2011/6/10 Brez Borland brez...@gmail.com: In your case Proxy acts as a UAC for Bob, so Client Behavior applies. Sorry, I missed your mail. So ok, thanks a lot. -- Iñaki Baz Castillo i...@aliax.net ___ Sip-implementors mailing list

[Sip-implementors] Sending TCP response with RFC 5626 after proxy restart

2011-06-09 Thread Roman Shpount
I am looking at implementation of RFC 5626 (SIP-OUTBOUND) and wanted to see what would be a proper scenario for sending responses for requests received over a flow which got disconnected before the response was sent. Imagine the following scenario: 1. Client registers and creates two TCP flows to