>>and any UAS insisting on an increase of one and one only would reject a
>>perfectly legitimate, in order, request.
No, that's not right. The UAS doesn't insist on an increment of one.
It only insists that CSeq is increasing.
>>If it is allowed for multiple transactions to exist, I must let them
>>if they want as it is they who build the final behaviour of their UA.
I really don't believe the intention was to allow multiple transactions
like this.
I agree, I can't find text to say it isn't allowed but Iñaki has argued
clearly that allowing it can cause problems.
Apart from the problems described by Iñaki, there are other issues:
1. Debugging is more difficult
2. It is an inefficent use of SIP resources
(it is effectively using the SIP transaction to queue up all the events)
3. it is an inefficient use of network bandwidth
(It is flooding the network with SIP messages.
If the network is busy or slow, it will only help
provoke congestion)
If you have events to send using INFO, you should queue them up.
Regards,
Attila
-----Original Message-----
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Stephen
Paterson
Sent: 05 May 2009 11:43
To: Iñaki Baz Castillo
Cc: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] Multiple concurrent transactions
OK, imagine UA1 establishes a dialog with UA2.
UA2 then sends two INFOs which arrive out of order. UA1's current remote CSeq
will be 0. The CSeq in the first INFO it receives can be anything so how would
the UAS know?
Also, even when only a single request is sent and the UAS does have a remote
CSeq a proxy may still attempt to authenticate the request in which case the
UAC would re-submit the request with an incremented CSeq. The UAS would not
have seen the original request, would not know that it had been authenticated
and any UAS insisting on an increase of one and one only would reject a
perfectly legitimate, in order, request.
Anyway, thanks for all your replies. From my perspective I just need to know
what I can and can not allow my customers to do. If it is allowed for multiple
transactions to exist, I must let them if they want as it is they who build the
final behaviour of their UA.
Steve
> -----Original Message-----
> From: sip-implementors-boun...@lists.cs.columbia.edu
> [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of
> Iñaki Baz Castillo
> Sent: 05 May 2009 11:27
> Cc: sip-implementors@lists.cs.columbia.edu
> Subject: Re: [Sip-implementors] Multiple concurrent transactions
>
> 2009/5/5 Rastogi, Vipul (Vipul) <vrast...@avaya.com>:
> > That is correct but here we are mixing network behavior
> with UAC behavior. UAC can send such MESSAGES, 3261 does not restrict
> UAC.
>
> Imagine a UAC wanting to send the following DTMF sequence to a GW
> (UAS):
> 1 2
> (yes, I know that INFO is not estandarized for DTMF's... but you
> understand me).
>
> Imagine that the UAC sends INFO "1" (CSeq 101) and before receiving a
> reply it also sends INFO "2" (CSeq 102).
> Due to network congestion (or whatever) the first INFO is lost.
> INFO "2" arrives to GW (CSeq 102).
> UAC retransmists INFO "1". This arrives now to GW which rejects it due
> to invalid CSeq (101 < 102).
>
> So, finally UAC has sent DTMF 2 before 1, breaking the desired DTMF
> sequence. Does it make sense?
> Yes, maybe RFC 3261 doesn't prohibit it *explicitely*, but IMHO it
> makes a lot of sense to avoid such UAC behaviour, don't you agree?
>
> Regards.
>
>
>
> --
> Iñaki Baz Castillo
> <i...@aliax.net>
>
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT,
UK Registration No: 1397386 (Wales) P Please consider the environment and don't
print this e-mail unless you really need to
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
