Subject: WG: [Sipping] Comments on draft-elwell-sipping-qsig2sip

From: "Alexeitsev, D" <[email-masked]>
Date: Wed, 29 May 2002 16:14:58 +0200

Hello John

Some comments inline

Thanks,
Denis Alexeitsev

-----Ursprüngliche Nachricht-----
Von: Elwell, John [mailto:[email-masked]]
Gesendet am: Mittwoch, 29. Mai 2002 15:31
An: 'Peterson, Jon'
Cc: [email-masked]
Betreff: RE: [Sipping] Comments on draft-elwell-sipping-qsig2sip

Jon,

Sure you can have an early dialog as a result of a 1xx (other than 100), but
in the situation where the destination QSIG network is awaiting more digits,
it will not normally send back a message that would cause the egress gateway
(SIP to QSIG) to send a 1xx. So I don't think this helps. I imagine this is
true also for ISUP.

The status quo seems to be that by delaying the cancellation of a previous
INVITE, the new INVITE with additional digits will most likely arrive at the
same egress gateway, can be associated with the existing QSIG/ISUP call and
can result in the sending of an INFO/SAM message. In the (less likely?) case
that it is routed to a different gateway, then we suffer the inefficiency
that the original QSIG/ISUP call is left waiting for more digits that it
will not receive and will be cancelled only when another INVITE receives a
final response. This disadvantage is probably outweighed by the greater
efficiency obtained in the (more likely?) case where the same gateway is
used.

[DA] Than it means, that there is no guarantee at all for the equal routing of subsequent INVITES.

One further thought. Receipt of a 1xx response that implies that sufficient
digits have been received (e.g., 180 Ringing) could be used to cancel any
previous INVITEs - it should not be necessary to wait for 200, which could
be many seconds later.

[DA] The INVITEs can only be ended by final responses, so it will require to change the SIP state machine 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP