PJSIP registration expiration - handling multiple contacts in server response

Asterisk Asterisk SIP
1

I’m having some problems relating to PJSIP’s outbound registration with an ITSP. I’m using v16.2.1. It appears that the crux of the problem comes down to two points:

  • The ITSP usually returns an expiration value that is shorter than I request (I know they’re allowed to do that, though I’m not sure why they do in this case)
  • When Asterisk re-registers 10s before that expiration, the ITSP OK response sometimes includes TWO entries in the Contact header, e.g. Contact: sip:something@x.x.x.x:yyyy;q=1;expires=10;received=“sip:x.x.x.x:yyyy”, sip:something@x.x.x.x:yyyy;q=1;expires=250;received=“sip:x.x.x.x:yyyy”
    (yes, those two entries are IDENTICAL other than the expires value. My Asterisk box is the ONLY client that is registered, so all Contact entries are me, just different register request times)

The second point (two Contact entries) appears to be the real issue for PJSIP, because in that case Asterisk seems to default to its requested expiration (300s in my case) and ignore the 250s that it seems it should have used from the ITSP response – maybe it fails to parse the two-entry response.

Of course, that means that Asterisk doesn’t re-register until 290 seconds later, so there is a 40 second window that we are NOT registered at the ITSP and any incoming calls will fail. Those are just example values, but typical.

The ITSP is Flowroute – I know sometimes you need to know that for best context. In this case it seems like their response is technically correct, and should be handled OK by Asterisk.

Is this an Asterisk bug? Is there a workaround?

2

As I read RFC 3261: SIP: Session Initiation Protocol the provider must updated the existing binding, not add a new one, so I don’t think the behaviour is technically correct.

You might want to note that normal bug reports are no longer being accepted on any version of Asterisk 16, and 16.2.1 will be quite old.

3

Thanks for the response and I see your point on the RFC. Makes sense. After a little more observation, this issue (multiple Contact entries) seems to come up when my Asterisk server chooses a different IP to REGISTER with than it did last time. In other words, if you follow the NAPTR and SRV records, there are serveral different hosts we could contact for any given request. When we happen to use a different IP than our last registration, that seems to be when the problem shows up. And in fact, for that brief time that the old registration is still active, Flowroute shows two registrations from me on the portal.

So with that said, am I doing anything incorrect here, or is this still looking like a Flowroute problem? Or are there any options that would avoid skipping around to different IPs? I suppose I could configure just one of the IPs or its specific hostname as a workaround, but that’s not ideal in the event of future Flowroute network changes.

4

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.