Re: Codec renegotiation failure on REFER

In any case if codec negotiations fails then 488 Media Not Acceptable is
only appropriate response.

-- 
Thanks & Regards,
Ravi Inder Singh.

On Sun, May 1, 2011 at 3:38 AM, Iñaki Baz Castillo <ibc <at> aliax.net> wrote:

> 2011/4/30 Nauman Sulaiman <nauman762-home <at> yahoo.co.uk>:
> > If codec negotiation fails on initial offer/answer exchange the usual
> response is 488 Not Acceptable. If it fails during the REINVITE stage
> > I have seen UAs send 500 Internal error. Is this correct or should it
> still be 488?
>
> In a UAS 500 means "UAS internal error", so it's never a proper
> response. 488 is the correct choice. A response is defined at
> transaction level, so an INVITE and re-INVITE are the same when coming
> to generate a response.
>
> --
> Iñaki Baz Castillo
> <ibc <at> aliax.net>
>
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors <at> lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>

Re: Codec renegotiation failure on REFER

> > If it fails during the REINVITE stage I have seen 
> > UAs send 500 Internal error. Is this correct or 
> > should it still be 488?

The answer depends upon why it is truly failing the request.  For instance, the following rfc3261 section
14.2 snippet shows one of the many reasons why a device may send a 500 response.  And even though 491 may be
more appropriate in some instances, some devices still send 500 with Retry-After during some glare and
other race condition situations.

   "A UAS that receives a second INVITE before it sends the final
   response to a first INVITE with a lower CSeq sequence number on the
   same dialog MUST return a 500 (Server Internal Error) response to the
   second INVITE and MUST include a Retry-After header field with a
   randomly chosen value of between 0 and 10 seconds."

> In a UAS 500 means "UAS internal error", so it's 
> never a proper response. 

The following RFC 3261 snippet provides what the 500 response means.  And similar to proxies, a B2BUA may
convert a received 503 to be a 500.

"21.5.1 500 Server Internal Error

   The server encountered an unexpected condition that prevented it from
   fulfilling the request.  The client MAY display the specific error
   condition and MAY retry the request after several seconds.

   If the condition is temporary, the server MAY indicate when the
   client may retry the request using the Retry-After header field."

Re: Codec renegotiation failure on REFER

2011/5/1 Brett Tate <brett <at> broadsoft.com>:
>> 488 is the correct choice.
>
> I agree that it is appropriate when 488 is the best response.  If not opposed to 6xx responses, the 606 may
be more accurate within some situations; however draft-ietf-sipping-sip-offeranswer-14 just
mentions 488.

No please, avoid 6XX responses. If a UAS replies 606 to an initial
INVITE it breaks the possible parallel forking.

--

-- 
Iñaki Baz Castillo
<ibc <at> aliax.net>

_______________________________________________
Sip-implementors mailing list
Sip-implementors <at> lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: Codec renegotiation failure on REFER

> >> 488 is the correct choice.
> >
> > I agree that it is appropriate when 488 is the best 
> > response.  If not opposed to 6xx responses, the 606 
> > may be more accurate within some situations; however 
> > draft-ietf-sipping-sip-offeranswer-14 just mentions 488.
> 
> No please, avoid 6XX responses. If a UAS replies 606 to 
> an initial INVITE it breaks the possible parallel forking.

Sounds like you want sipcore to adopt draft-worley-6xx-considered-harmful.

_______________________________________________
Sip-implementors mailing list
Sip-implementors <at> lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Re: Codec renegotiation failure on REFER

2011/5/2 Brett Tate <brett <at> broadsoft.com>:
>> > I agree that it is appropriate when 488 is the best
>> > response.  If not opposed to 6xx responses, the 606
>> > may be more accurate within some situations; however
>> > draft-ietf-sipping-sip-offeranswer-14 just mentions 488.
>>
>> No please, avoid 6XX responses. If a UAS replies 606 to
>> an initial INVITE it breaks the possible parallel forking.
>
> Sounds like you want sipcore to adopt draft-worley-6xx-considered-harmful.

I would prefer draft-sipcore-remove-6xx-responses :)

--

-- 
Iñaki Baz Castillo
<ibc <at> aliax.net>

_______________________________________________
Sip-implementors mailing list
Sip-implementors <at> lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

SIP TCP UDP missing ACK_UDP

Hello,

I do have a problem with SIP TCP+UDP.


The client is able to receive INVITE by UDP or TCP.

As the INVITE is bigger then 1300 bytes the UAS is sending it by TCP.

All responseS from client will be based on via_tcp  ( 100/100/200) and the contact from 200ok_sdp don’t
have the transport defined , then it means that the UAS should send the ACK by UDP.

The problem is: The UDP_ACK never arrives to client network.  ( then there is a re-tranmission for 200ok).

I am monitoring the network's switch and there is a UDP_ACK been send.


UAS ----> LAYER2 ---> ROUTER ---> LAYER2 ---> CLIENT  ( Missing  ACK).


Do you think the router or switch is dropping the UDP ?



Thanks!
Valdemar

Hello,

Re: SIP TCP UDP missing ACK_UDP

There is a problem in our Firewall.  The mixed TCP/UDP  same ip and same port have a bug, And then all ACK-UDP is
been dropped.

-----Original Message-----
From: sip-implementors-bounces <at> lists.cs.columbia.edu
[mailto:sip-implementors-bounces <at> lists.cs.columbia.edu] On Behalf Of ext Pavesi, Valdemar (NSN - US/Irving)
Sent: Monday, May 02, 2011 9:07 AM
To: sip-implementors <at> lists.cs.columbia.edu
Subject: [Sip-implementors] SIP TCP UDP missing ACK_UDP

Hello,

I do have a problem with SIP TCP+UDP.

The client is able to receive INVITE by UDP or TCP.

As the INVITE is bigger then 1300 bytes the UAS is sending it by TCP.

All responseS from client will be based on via_tcp  ( 100/100/200) and the contact from 200ok_sdp don’t
have the transport defined , then it means that the UAS should send the ACK by UDP.

The problem is: The UDP_ACK never arrives to client network.  ( then there is a re-tranmission for 200ok).

I am monitoring the network's switch and there is a UDP_ACK been send.

UAS ----> LAYER2 ---> ROUTER ---> LAYER2 ---> CLIENT  ( Missing  ACK).

Do you think the router or switch is dropping the UDP ?

Thanks!

Indicating a file transfer failure using MSRP

Hi all,

While dealing with file transfer in MSRP the following case happened
to me and I wonder if anyone run into it before or had any thoughts to
share.

Lets say we transfer file test.iso from Alice to Bob. Bob will
acknowledge the reception of every chunk of data just fine. Since I/O
operations usually take time to complete, we don't send the 200 to a
SEND when actual bytes are written, but when the chunk is received
over the network.

While the file transfer is in progress the disk becomes full because
some backup process kicked in and bytes can no longer be written to
disk. Or, the hard drive is faulty and after assembling all the chunks
together, the resulting hash differs from the original one. Either
way, this fail transfer didn't end well even if all chunks were
correctly sent and received over the wire.

Is there any standard mechanism to overcome this situations? I
couldn't find anything I could use on RFC 4975 nor RFC 5547. I guess
something like a 'final status report' would do. Is there such a thing
specified anywhere that I missed?

Thanks in advance,

--

-- 
/Saúl
http://saghul.net | http://sipdoc.net

Re: Indicating a file transfer failure using MSRP

2011/5/2 Saúl Ibarra Corretgé <saghul <at> gmail.com>:
> Lets say we transfer file test.iso from Alice to Bob. Bob will
> acknowledge the reception of every chunk of data just fine. Since I/O
> operations usually take time to complete, we don't send the 200 to a
> SEND when actual bytes are written, but when the chunk is received
> over the network.

It is specified nowhere that received bytes must be written to a file,
or to a DB or whatever, so the protocol can only assert the receipt of
the bytes from the network.

> While the file transfer is in progress the disk becomes full because
> some backup process kicked in and bytes can no longer be written to
> disk. Or, the hard drive is faulty and after assembling all the chunks
> together, the resulting hash differs from the original one. Either
> way, this fail transfer didn't end well even if all chunks were
> correctly sent and received over the wire.
>
> Is there any standard mechanism to overcome this situations? I
> couldn't find anything I could use on RFC 4975 nor RFC 5547. I guess
> something like a 'final status report' would do. Is there such a thing
> specified anywhere that I missed?

This is like when you send a mail. The SMTP protocol just asserts you
that the mail has been received in the destination server, but you
have no way to determine if it has been delivered to the final user
(let's forget mail-receipt-configuration features, who uses that?).

So IMHO, at SIP/MSRP protocol your scenario is working correctly. It's
not MSRP business the final usage/storage of the received data (and it

Re: Indicating a file transfer failure using MSRP

> This is like when you send a mail. The SMTP protocol just asserts you
> that the mail has been received in the destination server, but you
> have no way to determine if it has been delivered to the final user
> (let's forget mail-receipt-configuration features, who uses that?).
>

There is no concept of a 'session' in email, so the server can just
reply with an error, or send you an email back. In MSRP it might be
too late if the session is already finished.

> So IMHO, at SIP/MSRP protocol your scenario is working correctly. It's
> not MSRP business the final usage/storage of the received data (and it
> must not be). I assume that your SIP device should warn the user about
> the loss or corruption of the received data (but again, it has nothing
> to do with MSRP).
>

The problem is not warning the recipient, but warning the sender. I
see no means to communicate the sender *why* the transfer failed.

Regards,

--

-- 
/Saúl
http://saghul.net | http://sipdoc.net

_______________________________________________
Sip-implementors mailing list
Sip-implementors <at> lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors