1

the long string of NOTIFY messages happen after the called number answers. and after about 20-30 seconds the 503 happens and then the call connects fine with audio.first half of wireshark voip graphsecond half of wireshark voip graphlast bit of wireshark voip graph showing last rtp after all the notify messages

Adam Johns
  • 35,397
  • 25
  • 123
  • 176

1 Answers1

2

If that trace is for a single call it's an incredibly complex one. After spending a bit of time looking over it I don't think it is for a single call and instead there are a few different calls mixed up in it. It's complicated by the fact that 10.10.20.1 is a Back to Back User Agent (B2BUA) and is initiating its on calls in response to different events.

As to your question about the NOTIFY request it's originally generated by the UAC at 10.10.10.3 as part of what appears to be an attended transfer. The REFER request is the start of the transfer. An implicit subscription, which is what the NOTIFY request is part of, gets created for a REFER transaction (see https://www.rfc-editor.org/rfc/rfc3515 and also see https://www.rfc-editor.org/rfc/rfc4488 which deals with suppressing the implicit transaction).

For an attended transfer the NOTIFY request allows a call leg end point to indicate that the transfer has been processed successfully. In this case it looks like the user agent at 10.10.10.3 isn't happy to accept the transfer until it gets a response to its NOTIFY request. This is unusual behaviour as typically the NOTIFY requests are for just that, notifying agents of events not controlling call flow. Once 10.10.10.3 gets the 503 response to its NOTIFY request it finally starts sending the RTP to 10.10.20.4. It mustn't care what the response is as 503 is an error condition and would usually result in whatever was waiting for it to fail.

Community
  • 1
  • 1
sipsorcery
  • 30,273
  • 24
  • 104
  • 155
  • it is more complex than it should be because 10.10.10.1 and 10.10.20.1 are the same machine handling different vlans and it is also showing a findme-followme call. should 10.10.10.1 send the 503 sooner or should 10.10.10.3 not be waiting on a reply before it RTPs? I'm assuming by what you said that it appears it is 10.10.10.3's fault because it shouldn't wait on anything after NOTIFY before it RTPs – Adam Johns Jun 15 '12 at 13:16
  • RFC3515 doesn't actually spell out when a UA should start sending RTP as part of a REFER transaction, i.e. after the REFER is accepted or after the NOTIFY is acknowledged. However I've always implemented it as after the REFER is accepted. Something could go wrong with the NOTIFY, as in your case, and the call participants could be left hanging with dead air. If I was you I'd send the trace to your SIP server manufacturer (hope it's not Asterisk). – sipsorcery Jun 15 '12 at 23:31