See inline.
Iqbal wrote:
Hi
I have pstn -->ser -->UA
I also have asterisk hanging off ser for voicemail
Now this is all working fine, voicemail and all triggers great on no answer, BUT to be sure I decided to look atthe sip dialogue, just to see if all was fine, and so that I could start to clean up my config file. When a user calls from pstn, then hit the switch, and drop into ser, which then maps the pstn number to a local alias. Ip phone rings,
INVITE (pstn) to (ser) 100 trying (ser) to (pstn) INVITE (ser) to (ua) 100 trying (ua) to (ser) 180 ringing (ua) to (ser) 180 ringing (ser) to (pstn)
so far so good, now if there is no answer, and I forward to asterisk should there be a cancel to the original INVITE, cause this is what I am getting:
CANCEL (ser) to (ua) 200 OK (ua) to (ser) 487 request cancelled (ua) to (ser)
then i get ACK (ser) to (ua) ------where this ACK comes fro I am not sure
I believe the 487 does not need an ACK, but that the ACK is for the OK from ua.
200OK (ser) to (pstn) but useragent is no asterisk, hence this makes sense
This OK should be from Asterisk, right?! This OK will contain the SDP from Asterisk
ACK (pstn) to (ser)
This should go to Asterisk
so what I am not clear on is should the CANCEL be there, or not, it seems to make sense that it is, just want to confirm.
Yes, when the timer goes off, SER will cancel the INVITE. This is correct.
Also since alot of people have the same setup, would it be a good idea alongside onsip.org and its startup config, if we could post/have a sip trace of common call scenarios, I know some of these are in the rfc etc, but someone they dont seem user friendly...
Yes, good idea. We have been toying with the idea of standardized call scenarios using sipp that we can use for onsip.org testing to verify that everything works after changes have been done. We have focused on getting new issues out... So, if somebody would like to make some standard sipp scenarios that can be played using a script, we can certainly generate SIP traces for each config file as a reference. We need to remove the time added by ngrep and standardize on a username/domain, as well as do a replacelement on IP addresses, so that one can use diff to view any differences. :-)
g-)