Re: [Sip] Retransmission of INVITEs

[Jiri Kuthan <jiri.kuthan@fokus.fraunhofer.de>]

Hard to parse -- what are you exactly proposing to solve 
lost UDP/INVITE?

Thanks,

-Jiri

At 07:47 AM 10/9/2002, Jonathan Rosenberg wrote:


>Jiri Kuthan wrote:
>
>>>In any case, if the application is really concerned about this kind of
>>>failures, I think it can retransmit INVITEs even after a 100: 
>>
>>I agree as for implementations -- that breaks nothing and you can label your implementation as "added-value reliability UAC" ;-)
>>As for the specification, the INVITE UAC state machine simply
>>ignores this case. That's why it was raised on [sip] and not
>>[sip-implementers] and deserves IMHO an improvement.
>
>Well, it doesnt ignore it - it merely lumps it into another case (called party never answers) which requires the UAC at some point to give up and cancel. So, there is a call failure here when possibly there need not be. Thats not a bug in the spec, its a potential new feature if you want to add support for it.
>
>Anyway, nitpicks like that aside, there are some side effects to the proposed solution. Presumably, on retransmitting the INVITE and getting a failure, the client would try a backup server. Now, the problem is that the client cannot distinguish the case where the proxy failed before proxying the request, or after (but in both cases, before a final response or non-100 1xx). If it fails after proxying, trying a backup effectively results in a forked request. This can have unintended consequences. In a PSTN termination case, two PSTN gateways might get copies of the forked INVITE and then both make calls into the PSTN. If these happen to be for an 800 number or multiline call, you end up with potentially two calls created. Granted, one of them should be cancelled, but this is still undesirable behavior.
>
>My other concern is that the solution is UDP specific, and doesn't work for TCP. If we want to support this failure case for TCP, and we further assume failures without graceful closing of the connection, the client won't detect the failure as Henning pointed out. We could retransmit the INVITE on the TCP connection (yuck!), which is effectively like implementing application layer keepalives over TCP. I wonder what is the issue with TCP keepalives that make them infrequently used?
>
>Also, the retransmits over UDP exacerbate the bandwidth consumption of SIP for the common case where there is no failure. I guess this is not too bad if you stop retransmitting after non-100 1xx...
>
>-Jonathan R.
>-- 
>Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
>Chief Scientist                             First Floor
>dynamicsoft                                 East Hanover, NJ 07936
>jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
>http://www.jdrosen.net                      PHONE: (973) 952-5000
>http://www.dynamicsoft.com

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip