0

Is it possible to perform many SIP transactions in parallel, for a UA with two other UAs? Fpor example, if UA1 is in the middle of an INVITE, can UA1 respond to an incoming INVITE from UA3? What about standalone transactions?

Bob
  • 10,741
  • 27
  • 89
  • 143

2 Answers2

2

There's nothing in the standard that prevents a SIP device from handling multiple concurrent transactions and in fact SIP servers need to do so in order to be able to handle any kind of load.

As to how a SIP user agent should handle concurrent SIP transactions that's a separate consideration. IF UA1 is already on a call and a new INVITE request comes in from UA3 the typical way to handle it is with some kind of call waiting indication. With a softphone that indication can be visual whereas with an ATA that indication is often on the audio channel by injecting some tones into the UA's audio stream.

For non-INVITE transactions it will generally be a lot simpler since most don't require any user action. For example the UA could maintain half a dozen different registrations with different SIP servers and the various register and/or subscribe transactions (in this case the transaction is simply the combination of the request and response) could be running concurrently.

sipsorcery
  • 30,273
  • 24
  • 104
  • 155
  • For example, suppose UA1 sent a reINVITE to UA2 for session refresh, and UA3 is calling UA1. Are you saying that UA1 does not need to wait for the 20 OK from UA2, is that correct? Thanks. – Bob May 29 '12 at 17:04
  • Yep that's correct. There is nothing in the SIP standard that determines the order in which you need to process unrelated transactions. Where the transactions do have to be processed in order is the original invite from say UA2 must be completed before UA1 or UA2 can send a subsequent invite transaction for the same session. – sipsorcery May 29 '12 at 22:45
  • the SIP standard only defines what to do with transactions within the same dialog (call/session). If your UA has a dialog with one server/UA, any requests outside that session/dialog is completely independent and should have no effect on the other session unless you program your system to do so (you normally just notify the user so he can take an appropriate action) – Toote Jun 12 '12 at 01:14
2

There's another SIP parallel transactions "gothca-to-watch-for" too...

Within a sip dialog, if there are multiple UAC transactions started within a short space-of-time (~0.5s) and your transport in unreliable (UDP), there is a possible problem if the initial request packet is lost.

Lost packet with sequence number (CSeq) 'n' doesn't arrive, but the next packet does, containing CSeq n+1.

This is acceptable at the receiving (UAS) side, and it updates its knowledge of the "remote cseq" to 'n+1'.

The initial request is then resent, but CSeq 'n' is now lower then the remote-cseq, so MUST be discarded and the UAS responds with a (500 Server internal error).

Probably not what was expected!

So if your transport is "unreliable", you need to consider serialising requests with a dialog.

GreyMattR
  • 333
  • 2
  • 6