Re: [reSIProcate] DUM: Overlapping requests questions (repost)
The IETF crowd has waffled a couple of times on whether in dialog
requests can overlap. See this bug report for a sense of the
scope of the discussion:
http://bugs.sipit.net/sipwg/show_bug.cgi?id=686
Unfortunately, the extreme answers of allowing all overlapping and
allowing no overlapping are both wrong.
I propose this as a path forward for now:
When sending in a particular dialog:
- Allow one non-invite to overlap an invite.
- Do not allow a non-invite to overlap any other non-invite.
- Do not allow an invite to overlap another invite (this is clear
from 3261).
When receiving requests, assume the peer has made the
same choices.
RjS
On Wed, 2004-08-04 at 12:40, Alan Hawrylyshen wrote:
> [ Derek posted some fairly interesting and important questions. I am
> reposting and reparenting his questions so people with threading
> readers don't miss the follow-ups in case they marked the parent thread
> as uninteresting or read. -Alan]
>
> I'm working on non-invite transactions in a Dialog, and how they
> interact
> with each other; here are some questions.
>
> 1.) If I'm in an INVITE dialog, and I send an INFO message(for example),
> which I haven't received a response from yet, can I send a BYE or
> another
> non-INVITE transaction?
>
> 2.) Can INFO/MESSAGE/etc be sent in an early dialog?
>
> API questions:
>
> 1.) Which in dialog requests such as message should be part of the
> InviteSession API and which should be part of a dialog level API?
>
> 2.) If overlapping non-INVITE transactions are allowed, should we allow
> them
> in DUM?
>
> Derek
>
> Alan Hawrylyshen
> reSIProcate Project Administrator
> http://sipfoundry.org/reSIProcate/
> a l a n a t j a s o m i d o t c o m
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel