Re: [asterisk-users] Asterisk supports SIP-T?
On Wed, Feb 18, 2009 at 6:55 AM, Daviramos Roussenq Fortunato daviramo...@gmail.com wrote: How to convert SIP-T to SIP for Asterisk? You'll need to strip out ISUP MIME body in your SIP messaging with Asterisk. -- Raj Jain ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Asterisk supports SIP-T?
On Tue, Feb 17, 2009 at 1:06 PM, Daviramos Roussenq Fortunato daviramo...@gmail.com wrote: Asterisk supports SIP-T? Nope. Here is some old discussion on this topic: http://lists.digium.com/pipermail/asterisk-biz/2008-May/026690.html -- Raj Jain ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Is a=fmtp:101 0-15 a legal option in SDP ?
On Mon, Feb 9, 2009 at 4:43 PM, Olivier oza-4...@myamail.com wrote: Hi, My patton 4638 is sending : v=0 o=MxSIP 0 46 IN IP4 192.168.100.52 s=SIP Call c=IN IP4 192.168.100.52 t=0 0 m=audio 4984 RTP/AVP 8 101 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv m=image 4986 udptl t38 a=T38FaxUdpEC:t38UDPRedundancy a=sendrecv Asterisk (1.4.22.1) replies : Got unsupported a:fmtp in SDP offer Shall I care ? This error is somewhat benign. Basically, the end-point is telling that it can receive RFC 2833 events in the range of 0-15 (DTMF tones) and Asterisk is ignoring that range. -- Raj Jain ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] sip trunking and call transfer
On Sun, Nov 23, 2008 at 5:54 PM, Eric ManxPower Wieling [EMAIL PROTECTED]wrote: The term you are looking for is reinvite. Reinvites allow two devices to send audio directly between the two end points of the call. the SIGNALING stays on the servers, but the audio can be sent directly between the two end points. This still leaves the SIP signaling hairpin on Caller 2's system. nik600 wrote: a) Caller 1 - Trunk A/B - Trunk B/C - Caller3 or b) Caller 1 - Trunk A/C - Caller3 So: is it possible to avoid the scenario a) ? Yes, by using the SIP REFER method. Caller 2 will send a SIP REFER to Caller 1 asking it to talk to Caller 3. This will cause Caller 1 to drop it's session with Caller 2 and send a new INVITE to Caller 3. So, this is how you do it from a SIP protocol perspective. I'm not sure to what extent Asterisk supports this capability. -- Raj Jain ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] GEN-GEN and Manual Ring-Down (MRD)?
On Mon, Nov 10, 2008 at 6:56 AM, Tony Mountifield [EMAIL PROTECTED] wrote: Does anyone here know anything about GEN-GEN analogue circuits, also known as Manual Ring-Down (MRD)? Apparently they are widely used in Hoot'n'Holler systems for financial dealer-boards. I have been asked to try and interface to such circuits, and have been having great difficulty locating any specifications for the interface. Apparently, they are always-on 2-wire analogue circuits with no tip voltage or loop current, and on-demand superimposed ringing voltage in either direction for signalling (to do nothing more than get the remote end's attention). I was wondering whether it is possible to adapt an FXS or FXO port to operate in such a mode, but I'm not optimistic. Your understanding of MRD is correct (these are nailed-up connections with only ring-gen capability). I've personally not tried this w/ Asterisk FXS/FXO ports but If you can make it work that way pls. let us know. -- Raj Jain ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] SIP request send me 482 error
On Fri, Sep 19, 2008 at 5:29 AM, [EMAIL PROTECTED] wrote: Hi, I have a SIP request which comes from an Asterisk and which has to re-enter in the same Asterisk (during the same session), but during the second passage in Asterisk, it send me a 482 Loop Detected. So is it a bug or Asterisk control the session and considere it as a loop ? If it is not a bug, how could I resolve this problem ? Try setting pedantic=yes in your sip.conf. -- Raj Jain ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Asterisk T38 and Dialogic DMG 2000
JR, On Mon, Sep 8, 2008 at 3:08 PM, JR Richardson [EMAIL PROTECTED] wrote: The DMG invite sends to asterisk: m=audio 49016 RTP/AVP 0 101 [notice the m=audio] a=rtpmap:0 PCMU/8000/1 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 m=image 0 udptl t38 a=T38FaxRateManagement:transferredTCF a=T38FaxUdpEC:t38UDPRedundancy And Asterisk responds with the 200 OK: m=image 29475 udptl t38 [notice the m=image] a=T38FaxVersion:0 a=T38FaxFillBitRemoval:0 a=T38FaxTranscodingMMR:0 a=T38FaxTranscodingJBIG:0 a=T38FaxRateManagement:transferredTCF a=T38FaxMaxBuffer:400 a=T38FaxMaxDatagram:400 a=T38FaxUdpEC:t38UDPRedundancy I've been corresponding with Dialogic engineering on the messaging and they report that the gateway receiving m=image is not compatible or is telling the gw to immediately setup the call at T38 with is not compatible. The gateway wants to setup the call as audio first, hear the CNG tones and then re-invite to t38. That's how T.38 gateways typically work. This particular gateway seems to have some advanced knowledge that the call may be converted into T.38 later. They are offering m=image with port number set to 0 in the INVITE. By doing this, they seem to be offering a sort heads up that the call may be converted to T.38 later but no T.38 now because the port number is zero. This hint is of no use to Asterisk. If you can get the gateway to not send the m=image line in the first INVITE, they you may be in luck. So my question: Is there a way for configuring Asterisk to respond with m=audio instead of m=image? If I disable udptl in Asterisk, call setup fine with audio. This seems like a bug in Asterisk. Asterisk is encoding the SDP in 200 OK incorrectly on two fronts. It's dropping the m=audio line completely and it's activating T.38 stream when the remote end hasn't asked it to do so. -- Raj Jain ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] SIP or SCCP for cisco
On Mon, Jul 7, 2008 at 5:31 PM, M B [EMAIL PROTECTED] wrote: I have the option of running either SIP or SCCP for my cisco VoIP rollout..can someone shed light on what the pros/cons are? Seems everything is SIP these days so that's the option im leaning. Thanks- I'm not sure how this question relates to Asterisk and I don't have a list of pros/cons, but in my personal experience I've found their SCCP phone images to be a slight bit ahead of their SIP phone images in terms of features and operation. This could be due to business reasons. I've found and reported a few bugs on CUCM 6.X SIP stack (we didn't see these issues on their SCCP phones). That said, SIP is an open standard and I think you're leaning in the right direction if you expect you're phones to inter-operate with things other than CUCM in the future. -- Raj Jain ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Can asterisk support using different ip for rtp?
On Tue, Jun 24, 2008 at 9:26 PM, Jun Yin [EMAIL PROTECTED] wrote: Currently, RTP IP have to be the same as SIP IP. But, SIP RFC allows RTP to use different IP as SIP ip. Is there any way to configure it? GUI or CLI? or , will we support it in future? SIP is decoupled from RTP, so they can emanate from different IP addresses. Can you present a scenario where this will make sense (in the context where Asterisk is anchoring the media) ? -- Raj Jain ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] SIP over TCP development in 1.6 branch?
On Thu, Jun 19, 2008 at 3:50 PM, Paul Belanger [EMAIL PROTECTED] wrote: List, Could anybody speak to the status of development in 1.6 branch? I know support for SIP over TCP is pretty new / experimental but it seems active development of it has slowed or stopped in recent months. Is that a correct statement? Is SIP over TCP more a community project or something headed from Digium? I only ask to get a pulse of its status; not harp or demand people to work on it. Like everybody else, we have some dependencies on SIP over TCP, and have a few bugs open against it. Personally, I would love to help develop or submit patches for the bugs but would need a mentor for that. Either way, just looking to get some more info about the development status of it. I can't speak about the status of SIP/TCP development in Asterisk, but I can say the following: . I've tested Asterisk SIP/TCP and SIP/TLS against a variety of SIP implementations (acting as SIP peers) in a lab setting and things look okay. . I ran into a bug when I register a SIP end-point using SIP/TCP (http://bugs.digium.com/view.php?id=12282). . I think some of the challenges relating to deploying Asterisk SIP/TCP in production environments will be - connection management and NAT traversal. I think certain design thought needs to be put in SIP/TCP feature design to combat these issues. -- Raj Jain ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] strange SIP-SIP delay
On Tue, Jun 17, 2008 at 11:39 AM, Julian Lyndon-Smith [EMAIL PROTECTED] wrote: I've got the following setup: PhoneA - router - vpn - router- asterisk (SIP / ISDN) PhoneB - asterisk (SIP / ISDN) If phone A is connected to phone B (sip-sip), there is a noticable delay (up to 2-3 seconds) between me speaking and the other end hearing. If phone A calls out via the ISDN and back in to the DDI of phone B (ie SIP-ISDN-ISDN-SIP) then there is no delay at all ! Any clues on where I might start looking for this ? Are you using canreinvite=yes setting (i.e. is the RTP media expected to flow directly between the phones as opposed to hair-pining through Asterisk)? If so, some of the delay could be attributed to the time spent in RE-INVITEs that happen after the call set up. -- Raj Jain P.S. There is the directrtpsetup= flag that can eliminate this latency (if you're indeed using canreinvite=yes), but I believe that feature is considered experimental. Actually, if that feature is still experimental, I'd like to change that and fix any associated bugs because it seems like a pretty useful feature to me for people who want to use Asterisk as a call controller (a.k.a. soft-switch) that does not need to participate in the media path. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] SIP call, updated with CID as it becomes available
On Wed, Jun 11, 2008 at 9:17 AM, Brian J. Murrell [EMAIL PROTECTED] wrote: I'm wondering if the SIP lines can start ringing as soon as the zap line gets a call and when the zap line finally gets the CID, that is passed down to the already ringing SIP phones. This is actually an interesting problem. The SIP protocol didn't originally support this notion, but a recent extension to SIP adds this capability to the protocol. This concept is known as Connected-Identity in SIP and is defined in RFC 4916. The idea is to be able to update remote party's identity in either direction after the call has been answered or while it is ringing. I don't think people were really aware of the scenario that you've described, but it is an interesting one and I think RFC 4916 covers it. The thing though is that even if somebody added this capability to Asterisk, you'll need SIP phones that support this capability as well. Right now, I don't think there is any SIP phone out there that supports this. -- Raj Jain ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Asterisk On Public IP
On Mon, Jun 9, 2008 at 12:36 AM, Sanjoy Rath [EMAIL PROTECTED] wrote: I have installed Asterisk. I want friends to connect to my asterisk server from their SIP Phones are talk to me. I have tried two ways 1.) Have the Asterisk server run within the firewall, opened all the ports for that server in firewall port forwarding, does not work (One way audio issue). I have heard many thing about NAT issue etc. I have taken care of all the issues as suggested, never worked for me. This actually works. Try putting your Asterisk server in the DMZ as a test, if you think you've 'nat=yes', 'canreinvite=no' etc. configuration flags set right. Then I connected the linux server (asterisk server) directly to the internet (no firewall in between). The SIP phones would not connect to the server. It give 408 error. You're probably not receiving INVITEs in your Asterisk server. Setting 'sip set debug' on the console or Wireshark capture can prove this. One possibility is that the INVITEs are reaching your server but they are being blocked by SE-Linux (ip-tables) from reaching to your Asterisk application. -- Raj Jain ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Block on hold
The latter SDP seems invalid. It has an entirely different o= line from the previous SDP. Here is a quote from section 8 of RFC 3264 that describes this rule: When issuing an offer that modifies the session, the o= line of the new SDP MUST be identical to that in the previous SDP, except that the version in the origin field MUST increment by one from the previous SDP. -- Raj Jain On Fri, Jun 6, 2008 at 9:57 AM, Edgar Barbosa [EMAIL PROTECTED] wrote: Hi, I'm having a problem dialing out to a particular customer via a SIP provider. When this customer puts the call on hold on his pbx, our asterisk receives an INVITE with a SDP like this, and also puts the call on hold: v=0 o=ZTE 415 1 IN IP4 xxx.xxx.xxx.xxx s=phone-call c=IN IP4 xxx.xxx.xxx.xxx t=0 0 m=audio 15030 RTP/AVP 8 101 a=sendonly We also see on cli an Started music on hold, class 'default', on channel 'Local/[EMAIL PROTECTED],1' message. Then, when he releases the hold, we get a new INVITE with a SDP like this, but we can't get his audio any more: v=0 o=root 2842 2843 IN IP4 xxx.xxx.xxx.xxx s=session c=IN IP4 xxx.xxx.xxx.xxx t=0 0 m=audio 18240 RTP/AVP 8 101 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=silenceSupp:off - - - - a=ptime:20 a=recvonly Is there any way of blocking this kind of notifications? We really don't need to get this external on hold messages. I've tried setting allowexternalinvites=no on sip.conf, but there's no difference... Thanks, Edgar ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] (Newbie)How to reduce security risks in opening IAX Sip Ports
One way to make the system more secure would be by not opening these ports statically in Linux iptables. I have not tested this, but Linux iptables have shipped with ip_nat_sip and ip_conntrack_sip modules since kernel version 2.6.18. With these modules, Linux iptables will act as a SIP-aware NAT that opens the ports dynamically depending on what's exchanged in the signaling. -- Raj Jain On Tue, May 20, 2008 at 4:41 AM, Shaun Wingrin [EMAIL PROTECTED] wrote: Please direct me to any usefull links to help secure my asterisk server once these ports are opened. Thanks Shaun ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] (Newbie)How to reduce security risks in opening IAX Sip Ports
On Tue, May 20, 2008 at 7:11 AM, Tzafrir Cohen [EMAIL PROTECTED] wrote: On Tue, May 20, 2008 at 06:46:49AM -0400, Raj Jain wrote: One way to make the system more secure would be by not opening these ports statically in Linux iptables. I have not tested this, but Linux iptables have shipped with ip_nat_sip and ip_conntrack_sip modules since kernel version 2.6.18. With these modules, Linux iptables will act as a SIP-aware NAT that opens the ports dynamically depending on what's exchanged in the signaling. Err... and if you want to allow someone to connect to UDP port 5060 of your boxm what iptables trick should you use? My comment was about RTP/RTCP ports (I should have been clearer). SIP signaling ports will have to be opened statically. Although, for added security you could open the port as symmetric if you know the ip/port of someone that wants to connect to you as opposed to opening it in a full-cone way. Also, I'm curious as to what experience others have had with ip_nat_sip and ip_conntrack_sip modules. Do they really work? -- Raj Jain ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Problem with incoming calls on Broadvoice after upgrade to 1.4.18
Looking at the trace, the entity sending you the INVITE is not resubmitting INVITE with credentials after the initial INVITE was challenged with a 401 response by Asterisk. The trace shows two independent calls and both have the same problem. -- Raj Jain mailto:rj2807 at gmail dot com sip:rjain at iptel dot org On Sun, Mar 16, 2008 at 4:10 PM, Jon Miron [EMAIL PROTECTED] wrote: Hi all, I just upgraded to Asterisk 1.4.18 a few days ago and I don't use Broadvoice TOO often, however I have a Vermont number with them and so my mother in law calls it to talk to my wife once in a while, so that's why it took me so long to notice it wasn't working. Anyway, when she calls she gets a busy signal (as I've tested when calling it from my cell). When I enable debugging I get the following: SIP Debugging Enabled for IP: 147.135.0.128 net-xero*CLI --- SIP read from UDP://147.135.0.128:5060 --- INVITE sip:my Broadvoice #@servers IP:5060 SIP/2.0 Call-ID: [EMAIL PROTECTED] CSeq: 1 INVITE From: Toronto ONsip:my cell #@147.135.0.128;user=phone;tag=prtu To: my namesip:s@servers IP Via: SIP/2.0/UDP 147.135.0.128:5060 Contact: sip:my cell #@147.135.0.128:5060 Supported: 100rel Content-Length: 309 Content-Type: application/sdp v=0 o=2475098871 10 10 IN IP4 147.135.2.247 s=- c=IN IP4 147.135.2.250 t=0 0 m=audio 28274 RTP/AVP 0 8 18 96 97 101 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:96 iLBC/8000 a=fmtp:96 mode=30 a=rtpmap:97 t38/8000 a=rtpmap:101 telephone-event/8000 - --- (10 headers 14 lines) --- == Using SIP RTP CoS mark 5 Sending to 147.135.0.128 : 5060 (no NAT) Using INVITE request as basis request - [EMAIL PROTECTED] No user 'my cell #' in SIP users list Found peer 'sip.broadvoice.com' for 'my cell #' from 147.135.0.128:5060 net-xero*CLI --- Reliably Transmitting (no NAT) to 147.135.0.128:5060 --- SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP 147.135.0.128:5060;received=147.135.0.128 From: Toronto ONsip:my cell #@147.135.0.128;user=phone;tag=prtu To: my namesip:s@servers IP;tag=as77a74c13 Call-ID: [EMAIL PROTECTED] CSeq: 1 INVITE User-Agent: Asterisk PBX SVN-trunk-r106946 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces, timer WWW-Authenticate: Digest algorithm=MD5, realm=asterisk, nonce=06b61489 Content-Length: 0 Scheduling destruction of SIP dialog '[EMAIL PROTECTED]' in 32000 ms (Method: INVITE) net-xero*CLI --- SIP read from UDP://147.135.0.128:5060 --- ACK sip:my Broadvoice #@servers IP:5060 SIP/2.0 Call-ID: [EMAIL PROTECTED] CSeq: 1 ACK From: Toronto ONsip:my cell #@147.135.0.128;user=phone;tag=prtu To: my namesip:s@servers IP;tag=as77a74c13 Via: SIP/2.0/UDP 147.135.0.128:5060 Content-Length:0 - --- (7 headers 0 lines) --- [Mar 16 15:52:39] NOTICE[27524]: chan_sip.c:9020 sip_reregister:-- Re-registration for my Broadvoice #@sip.broadvoice.com REGISTER 12 headers, 0 lines Reliably Transmitting (no NAT) to 147.135.0.128:5060: REGISTER sip:sip.broadvoice.com SIP/2.0 Via: SIP/2.0/UDP servers IP:5060;branch=z9hG4bK339bbe4e;rport Max-Forwards: 70 From: sip:my Broadvoice #@sip.broadvoice.com;tag=as2a457f50 To: sip:my Broadvoice #@sip.broadvoice.com Call-ID: [EMAIL PROTECTED] CSeq: 104 REGISTER User-Agent: Asterisk PBX SVN-trunk-r106946 Expires: 120 Contact: sip:s@servers IP Event: registration Content-Length: 0 --- net-xero*CLI --- SIP read from UDP://147.135.0.128:5060 --- SIP/2.0 200 OK Call-ID: [EMAIL PROTECTED] CSeq: 104 REGISTER From: sip:my Broadvoice #@sip.broadvoice.com;tag=as2a457f50 To: sip:my Broadvoice #@sip.broadvoice.com Via: SIP/2.0/UDP servers IP:5060;branch=z9hG4bK339bbe4e Contact: sip:s@servers IP Expires: 30 Event: registration Content-Length:0 - --- (10 headers 0 lines) --- Scheduling destruction of SIP dialog '[EMAIL PROTECTED]' in 32000 ms (Method: REGISTER) [Mar 16 15:52:39] NOTICE[27524]: chan_sip.c:14949 handle_response_register: Outbound Registration: Expiry for sip.broadvoice.com is 30 sec (Scheduling reregistration in 23 s) net-xero*CLI --- SIP read from UDP://147.135.0.128:5060 --- INVITE sip:my Broadvoice #@servers IP:5060 SIP/2.0 Call-ID: [EMAIL PROTECTED] CSeq: 1 INVITE From: Toronto ONsip:my cell #@147.135.0.128;user=phone;tag=ikmn To: my namesip:s@servers IP Via: SIP/2.0/UDP 147.135.0.128:5060 Contact: sip:my cell #@147.135.0.128:5060 Supported: 100rel Content-Length: 309 Content-Type: application/sdp v=0 o=2475098871 10 10 IN IP4 147.135.2.247 s=- c=IN IP4 147.135.2.250 t=0 0 m=audio 28276 RTP/AVP 0 8 18 96 97 101 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:96 iLBC/8000 a=fmtp:96 mode=30 a=rtpmap:97 t38/8000 a=rtpmap
Re: [asterisk-users] Problem with incoming calls on Broadvoice after upgrade to 1.4.18
Based on the trace alone, it seems like a problem on their end. You may want to try shutting off INVITE authentication (by commenting out secret= line in your sip.conf) to see if the call goes through. On Sun, Mar 16, 2008 at 6:27 PM, Jon Miron [EMAIL PROTECTED] wrote: Hi Raj, Thanks for your response. I'm a little confused though. Does this look as if it's a problem with Broadvoice itself, and not my configuration? Any time I've called them with problems where it's clearly not my fault (ie nothing on my end has changed), they're never very helpful. On Sun, Mar 16, 2008 at 4:45 PM, Raj Jain [EMAIL PROTECTED] wrote: Looking at the trace, the entity sending you the INVITE is not resubmitting INVITE with credentials after the initial INVITE was challenged with a 401 response by Asterisk. The trace shows two independent calls and both have the same problem. -- Raj Jain mailto:rj2807 at gmail dot com sip:rjain at iptel dot org On Sun, Mar 16, 2008 at 4:10 PM, Jon Miron [EMAIL PROTECTED] wrote: Hi all, I just upgraded to Asterisk 1.4.18 a few days ago and I don't use Broadvoice TOO often, however I have a Vermont number with them and so my mother in law calls it to talk to my wife once in a while, so that's why it took me so long to notice it wasn't working. Anyway, when she calls she gets a busy signal (as I've tested when calling it from my cell). When I enable debugging I get the following: SIP Debugging Enabled for IP: 147.135.0.128 net-xero*CLI --- SIP read from UDP://147.135.0.128:5060 --- INVITE sip:my Broadvoice #@servers IP:5060 SIP/2.0 Call-ID: [EMAIL PROTECTED] CSeq: 1 INVITE From: Toronto ONsip:my cell #@147.135.0.128;user=phone;tag=prtu To: my namesip:s@servers IP Via: SIP/2.0/UDP 147.135.0.128:5060 Contact: sip:my cell #@147.135.0.128:5060 Supported: 100rel Content-Length: 309 Content-Type: application/sdp v=0 o=2475098871 10 10 IN IP4 147.135.2.247 s=- c=IN IP4 147.135.2.250 t=0 0 m=audio 28274 RTP/AVP 0 8 18 96 97 101 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:96 iLBC/8000 a=fmtp:96 mode=30 a=rtpmap:97 t38/8000 a=rtpmap:101 telephone-event/8000 - --- (10 headers 14 lines) --- == Using SIP RTP CoS mark 5 Sending to 147.135.0.128 : 5060 (no NAT) Using INVITE request as basis request - [EMAIL PROTECTED] No user 'my cell #' in SIP users list Found peer 'sip.broadvoice.com' for 'my cell #' from 147.135.0.128:5060 net-xero*CLI --- Reliably Transmitting (no NAT) to 147.135.0.128:5060 --- SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP 147.135.0.128:5060;received=147.135.0.128 From: Toronto ONsip:my cell #@147.135.0.128;user=phone;tag=prtu To: my namesip:s@servers IP;tag=as77a74c13 Call-ID: [EMAIL PROTECTED] CSeq: 1 INVITE User-Agent: Asterisk PBX SVN-trunk-r106946 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces, timer WWW-Authenticate: Digest algorithm=MD5, realm=asterisk, nonce=06b61489 Content-Length: 0 Scheduling destruction of SIP dialog '[EMAIL PROTECTED]' in 32000 ms (Method: INVITE) net-xero*CLI --- SIP read from UDP://147.135.0.128:5060 --- ACK sip:my Broadvoice #@servers IP:5060 SIP/2.0 Call-ID: [EMAIL PROTECTED] CSeq: 1 ACK From: Toronto ONsip:my cell #@147.135.0.128;user=phone;tag=prtu To: my namesip:s@servers IP;tag=as77a74c13 Via: SIP/2.0/UDP 147.135.0.128:5060 Content-Length:0 - --- (7 headers 0 lines) --- [Mar 16 15:52:39] NOTICE[27524]: chan_sip.c:9020 sip_reregister:-- Re-registration for my Broadvoice #@sip.broadvoice.com REGISTER 12 headers, 0 lines Reliably Transmitting (no NAT) to 147.135.0.128:5060: REGISTER sip:sip.broadvoice.com SIP/2.0 Via: SIP/2.0/UDP servers IP:5060;branch=z9hG4bK339bbe4e;rport Max-Forwards: 70 From: sip:my Broadvoice #@sip.broadvoice.com;tag=as2a457f50 To: sip:my Broadvoice #@sip.broadvoice.com Call-ID: [EMAIL PROTECTED] CSeq: 104 REGISTER User-Agent: Asterisk PBX SVN-trunk-r106946 Expires: 120 Contact: sip:s@servers IP Event: registration Content-Length: 0 --- net-xero*CLI --- SIP read from UDP://147.135.0.128:5060 --- SIP/2.0 200 OK Call-ID: [EMAIL PROTECTED] CSeq: 104 REGISTER From: sip:my Broadvoice #@sip.broadvoice.com;tag=as2a457f50 To: sip:my Broadvoice #@sip.broadvoice.com Via: SIP/2.0/UDP servers IP:5060;branch=z9hG4bK339bbe4e
Re: [asterisk-users] Shared Extension
Tony,
This sounds reasonable. Today when Dial forks a call, the first
extension that answers wins. It seems that you want to extend this
mechanism to say that when Dial forks a call, the first extension
that reports busy wins. Sounds like a nice enhancement to Dial.
Raj
On Mon, Mar 10, 2008 at 7:57 PM, Tony Plack [EMAIL PROTECTED] wrote:
Raj,
I would say you understand exactly. It is kind of a SLA, but not.
SLA does great with a inbound trunk line and multiple extensions, but even
in SLA, if one extension is busy, the others ring.
There is no way to tell asterisk that if it gets a busy on one of the
channels, that the extension is busy, period.
The terminology to say that multiple extensions appear as a single extension
is not correct either. To say that you would have to define an extension in
the system and that each of these extension numbers is pooled in a Local type
dial command to the single extension. So because that terminology is not
adequate, I am using one extension to multiple channels.
I am trying to create a single extension to multiple channels (lines) {exten
= 5000,1,Dial(SIP\1234SIP\phoneLocal\12225551212)} but respecting busy on
any channel is busy on the extension. Almost the reverse of SLA, but with
all the behavior of a single extension to a single channel {exten =
5000,1,Dial(SIP\1234)}
Thanks for working with me to clarify.
Tony Plack
I don't quite understand the use case, but it sounds like you may
be trying to do shared line appearances
(http://asterisk.org/node/48342). You seem to be alluding that you
want multiple extensions to share the state of a single extension.
If that is the case, then SLA isn't quite that. Also, Asterisk SLA
doesn't support a notion of call appearance where a single
extension can receive multiple calls.
--
Raj
___
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
--
Raj Jain
mailto:rj2807 at gmail dot com
sip:rjain at iptel dot org
___
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Microsoft Office Communications Server
I'd concur that allowing SIP to be transported over UDP was one of the biggest mistakes made in the initial protocol design. In addition to the issues stated below (such as IP fragmentation and how that impacts NAT traversal), there are other unsolvable problems w/ SIP/UDP such as when a request is smaller than path MTU and is therefore sent over UDP but the response exceeds the MTU size - how do you deliver the response then?. If there is ever a SIP 3.0, I believe there is enough consensus that it'll not support UDP transport. -- Raj On Mon, Mar 10, 2008 at 9:29 PM, Philipp von Klitzing [EMAIL PROTECTED] wrote: Hi! What is the logic of them using SIP over TCP? Is this a broad industry trend? Or just the latest attempt to get around SIP/NAT issues? I remember a quote of Henning Schulzrinne where he states that having designed SIP with UDP in mind was the biggest mistake he (and Mark Handle?) were to be found guilty of. I am not sure if this is what's driving Microsoft's decisions, my guess is that this is/was mostly driven by security reasons (and the new focus of Microsoft on security aspects). Cheers, Philipp * Taken from http://www.faqs.org/rfcs/rfc4168.html: 3.1. Advantages over UDP All the advantages that SCTP has over UDP regarding SIP transport are also shared by TCP. Below, there is a list of the general advantages that a connection-oriented transport protocol such as TCP or SCTP has over a connection-less transport protocol such as UDP. Fast Retransmit: SCTP can quickly determine the loss of a packet, because of its usage of SACK and a mechanism that sends SACK messages faster than normal when losses are detected. The result is that losses of SIP messages can be detected much faster than when SIP is run over UDP (detection will take at least 500 ms, if not more). Note that TCP SACK exists as well, and TCP also has a fast retransmit option. Over an existing connection, this results in faster call setup times under conditions of packet loss, which is very desirable. This is probably the most significant advantage of SCTP for SIP transport. Congestion Control: SCTP maintains congestion control over the entire association. For SIP, this means that the aggregate rate of messages between two entities can be controlled. When SIP is run over TCP, the same advantages are afforded. However, when run over UDP, SIP provides less effective congestion control. This is because congestion state (measured in terms of the UDP retransmit interval) is computed on a transaction-by-transaction basis, rather than across all transactions. Thus, congestion control performance is similar to opening N parallel TCP connections, as opposed to sending N messages over one TCP connection. Transport-Layer Fragmentation: SCTP and TCP provide transport-layer fragmentation. If a SIP message is larger than the MTU size, it is fragmented at the transport layer. When UDP is used, fragmentation occurs at the IP layer. IP fragmentation increases the likelihood of having packet losses and makes NAT and firewall traversal difficult, if not impossible. This feature will become important if the size of SIP messages grows dramatically. * Quote from http://tools.ietf.org/html/draft-jennings-sip-dtls-01: There has been considerable discussion of why SIP needs DTLS when we have TLS. This is the wrong question. The right question is why SIP has UDP and TCP (not to mention SCTP). There are two reasons for believing that UDP is likely to be an important protocol in SIP for the foreseeable future. o In theory, there is no problem building systems that terminate a million TCP connections on a single host. In practice, the common operating systems used for building SIP aggregation devices make this impossible. To date, no one has demonstrated terminating over 100k SIP TCP connections to a single host. Doing that many connections with UDP has not been difficult. o If we want to talk about running code for SIP, it's UDP. Unless UDP is deprecated for SIP, it is important to provide a reasonable level of security for it. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] sip show channels - gives a growing list of dead channels
Asterisk SIP channels can hang for a variety of reasons such as network errors, signaling malfunction and software bugs. These are difficult to track down and sometimes the root cause is not even in your control. In order to provide a sort of garbage collection mechanism for such hung SIP channels, Asterisk 1.6 supports a mechanism called as SIP Session Timers. You may want to give this feature a shot. The instructions for configuring it are in sip.conf. -- Raj On Mon, Mar 10, 2008 at 5:13 PM, Keith Hardee [EMAIL PROTECTED] wrote: I feel like I've seen that error before, but I did some quick testing and was not able to produce the error. CLI level was greater than 206 (many v's) callfromto hangup Test 1polycom spectralink polycom Test 2polycom spectralink spectralink Test 3spectralink polycom polycom Test 4spectralink polycom spectralink Test 5 spectralink spectralink spectralink I only did one test of each above because I am not in office (had someone doing tests while I watched CLI). I can test more when I get back Thursday. Thanks for input. On Sat, Mar 8, 2008 at 2:59 AM, Fons van der Beek [EMAIL PROTECTED] wrote: Same problem over here I use KIRK-Telecom ip600v3 This only happens on calls between SIP en MiSDN, anyone any clue? As far as i can see these dead calls once in while occur when the remote party first hangs up (remote=MiSDN channel) Keith do you also have error messages in the CLI when you open asterisk by using asterisk -rvv ? (a lot of v) -- Incoming call: Got SIP response 400 Bad Request back from 10.0.0.71 10.0.0.71 represents the IP number of internal phone Keith Hardee schreef: I am using Asterisk 1.4.18 with 70 various Polycoms, 12 analog, and 18 Spectralink wireless IP phones. Most of the Spectralink phones have entries in 'sip show channels' that do not go away. None of the other phones do this. Is there anyway to remove these entries without restarting Asterisk? Any ideas on what could be done to prevent this? Example output: xxx.xxx.xxx.xxx 541 14dd18886d1 00103/00102 0x0 (nothing) No Rx: BYE xxx.xxx.xxx.xxx 546 1e7c2fd84ab 00103/00102 0x0 (nothing) No (d) Rx: BYE xxx.xxx.xxx.xxx 546 80f99ee6-6c 00103/00104 0x0 (nothing) No Rx: BYE xxx.xxx.xxx.xxx 546 0d9b184254b 00104/00102 0x0 (nothing) No Rx: BYE xxx.xxx.xxx.xxx 546 7fa08c964a1 00104/00102 0x0 (nothing) No Rx: BYE xxx.xxx.xxx.xxx 542 7088c6a7-db 00102/00104 0x0 (nothing) No Rx: BYE xxx.xxx.xxx.xxx 541 424cc109052 00104/00102 0x0 (nothing) No Rx: BYE xxx.xxx.xxx.xxx 541 225fe5130e5 00104/00102 0x0 (nothing) No Rx: BYE Thanks, Keith ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users -- Raj Jain mailto:rj2807 at gmail dot com sip:rjain at iptel dot org ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Shared Extension
I don't quite understand the use case, but it sounds like you may be trying to do shared line appearances (http://asterisk.org/node/48342). You seem to be alluding that you want multiple extensions to share the state of a single extension. If that is the case, then SLA isn't quite that. Also, Asterisk SLA doesn't support a notion of call appearance where a single extension can receive multiple calls. -- Raj On Mon, Mar 10, 2008 at 11:00 AM, Tony Plack [EMAIL PROTECTED] wrote: I am working on a project that requires shared extension. Where shared line looks at the status of a line/trunk, shared extension would look at a series of channels as the same extension. The users would like to add destination channels on the fly, to provide roaming extensions, but maintaining fixed channels as well. If a call comes in on an extension, the system needs to honor the fact that channel 1 is busy, therefore, the extension is busy. Keep in mind that the channel could be anything including SIP outbound trunk channels (read cell phone or hotel room). The Dial command does provide a nice multi-channel dialer, especially with the r option, however, if one of the lines is busy, the system will keep ringing the other lines until timeout or answer (read voice mail). So I am contemplating adding a feature to the dial command, that would make any channel busy, cause the initial Dial to come back as busy. Kind of a force the state flag. Before I brake into code, does anyone have any other ideas? This would also help with phones like Grandstream, where you have 4 accounts to configure, and would like to have all 4 SIP accounts act as 1 extension. Tony Plack ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users -- Raj Jain mailto:rj2807 at gmail dot com sip:rjain at iptel dot org ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] load balancing SIP extensions
On Fri, 22 Feb 2008 19:44 +0200, Yehavi Bourvine +972-8-9489444 [EMAIL PROTECTED] wrote: When a call arrives I check whether the REGSERVER coloumn is the same as the local server or not. If not, then there are two options: - Pass the call via IAX to the other servers; this makes both server process the call and the audio. - Send a refer message to the caller to contact the other server. You may actually want to use a redirect message for this (e.g SIP 302 response). In any case, traversing only one server in the signaling/media path as opposed to two would generally seem more efficient. -- Raj Jain mailto:rj2807 at gmail dot com sip:rjain at iptel dot org ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] SIP over TCP
SIP over TCP is included in 1.6. http://svn.digium.com/view/asterisk/tags/1.6.0-beta1/CHANGES?view=co On Feb 13, 2008 5:21 PM, Razza [EMAIL PROTECTED] wrote: I am aware there is a SIP over TCP patch. Will this ever become part of a release, if so are there any timelines? Thanks in advance. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users -- Raj Jain mailto:rj2807 at gmail dot com sip:rjain at iptel dot org ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Intercepting DTMF to initiate Voice Drop
Transfer does not work for Voice Drop because it adds significant
delay from the time the transfer key is pressed and the transfer
extension is dialed to the playback.
Voice Drop has a critical requirement that the switchover from A's
speaking voice to announcement playback needs to be as seamless as
possible. The person picking up the message on the answering machine
must not be able to detect a gap between the two voices. That is why
this needs to be done in one shot.
On Jan 25, 2008 11:41 AM, Don Pobanz [EMAIL PROTECTED] wrote:
From: Raj Jain - Friday, January 25, 2008 10:07 AM
I'm trying to implement a Voice Drop service within Asterisk
dial-plan. The service is supposed to work as following:
1. A initiates a call to B
2. The call is answered by B's answering machine
3. A hears the answering machine's greeting and the recording beep
4. A speaks a few words into the recording to personalize the message
5. A presses some DTMF keys (say, '##') to initiate Voice Drop
6. PBX intercepts DTMF and starts playing a prerecorded
announcement to B
7. A is released from the call as soon as the Voice Drop is initiated
8. PBX releases the call to B at the end of the announcement
Any thoughts, ideas?
After talking with B, A could transfer the call to an extension such as
123 with a dial plan something like:
Exten = 123,1,Playback(file)
Exten = 123,n,Playback(file)
Exten = 123,n,hangup
A will need to be able to transfer outgoing calls ('T' option).
Don Pobanz
___
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
--
Raj Jain
mailto:rj2807 at gmail dot com
sip:rjain at iptel dot org
___
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
[asterisk-users] Intercepting DTMF to initiate Voice Drop
Hi, I'm trying to implement a Voice Drop service within Asterisk dial-plan. The service is supposed to work as following: 1. A initiates a call to B 2. The call is answered by B's answering machine 3. A hears the answering machine's greeting and the recording beep 4. A speaks a few words into the recording to personalize the message 5. A presses some DTMF keys (say, '##') to initiate Voice Drop 6. PBX intercepts DTMF and starts playing a prerecorded announcement to B 7. A is released from the call as soon as the Voice Drop is initiated 8. PBX releases the call to B at the end of the announcement To acheive this I need to intercept DTMF in the middle of a call and initiate an action based on that. I couldn't find an option in the Dial() application to break out of it on receipt of a particular DTMF sequence. Does the Dial() application support such a capability? I've tried the 'G' option in the Dial() application but that splits the call as soon as it is answered, whereas, I need to split the call after it is established based on a DTMF stimulus. Are there any other ways of accomplishing this goal? Any thoughts, ideas? Thank you, Raj Jain mailto:rj2807 at gmail dot com sip:rjain at iptel dot org ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] How to check if a SIP phone isforwardedwithout ringing it ?
Olle, Yes, OPTIONS is too heavy for keep-alives and conflicts with its intended usage - capability discovery without actually placing a call. The IETF seems to be finally reaching a conclusion on how to do keep-alives in a lightweight fashion. These are described in the SIP-outbound draft: http://www.ietf.org/internet-drafts/draft-ietf-sip-outbound-11.txt Basically, the idea is to use STUN for SIP/UDP and a CRLF packet for SIP/TCP. -- Raj -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Johansson Olle E Sent: Wednesday, January 09, 2008 1:50 AM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] How to check if a SIP phone isforwardedwithout ringing it ? 9 jan 2008 kl. 02.48 skrev Raj Jain: This issue of phone vendors not supporting OPTIONS according to RFC 3261 often comes up on this list. Like Kevin Fleming said, an OPTIONS request is supposed to be responded in the same way as an INVITE. Almost all SIP phone vendors have construed OPTIONS as some kind of a keep-alive request, which is wrong. Which we do too, by the way. In worst case, maybe Asterisk has set this industry standard. OPTIONS is far to heavy in processing on the server side to be used for keep-alives. I'm starting to see devices that use it for checking capabilities - the proper way. To do this properly, we will have to authenticate the OPTIONs request and match it with the proper peer/ user to get the proper codec settings, ACLs and such. Since all versions of Asterisk use OPTIONs for NAT-keepalives, I'm a bit hesitant to fix this. It's a catch 22. I want to do it properly, but then the amount of processing for each OPTIONs request that we receive is going to be a bit too much. Maybe one could ask vendors to add a header to the OPTIONs packet saying this is just a keep-alive. Give me a 200 OK without any parsing and be happy, because I don't care about the reply. Linksys has a setting and use NOTIFY for Keep-alives, which also is a poor solution, but at least something we can just give an error response to without a lot of processing. There was a proposal for PING, but it never got anywhere. /O ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] How to check if a SIP phone isforwardedwithout ringing it ?
There is something called as answer-mode in SIP. The idea is to allow the UAC to request the UAS to auto-answer the call. At least in theory, this could be used to check the status of the phone without ringing it. This is obviously not an ideal replacement of OPTIONS. Also, this is a new spec so I'm not sure how many phone vendors support it yet: http://www.ietf.org/internet-drafts/draft-ietf-sip-answermode-06.txt -- Raj From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Olivier Sent: Wednesday, January 09, 2008 1:47 AM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] How to check if a SIP phone isforwardedwithout ringing it ? As using OPTIONS requests main benefit is to non-phone specific, what shall we do when most vendors do not comply with RFC ? 2008/1/9, Raj Jain [EMAIL PROTECTED] : This issue of phone vendors not supporting OPTIONS according to RFC 3261 often comes up on this list. Like Kevin Fleming said, an OPTIONS request is supposed to be responded in the same way as an INVITE. Almost all SIP phone vendors have construed OPTIONS as some kind of a keep-alive request, which is wrong. Can we ask the phone vendors to play by the book? -- Raj From: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Olivier Sent: Tuesday, January 08, 2008 7:50 AM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] How to check if a SIP phone is forwardedwithout ringing it ? 2008/1/7, Kevin P. Fleming [EMAIL PROTECTED]: Olivier wrote: Is there way for an Asterisk server to check if a sip phone is forwarded without bothering phone's user ? No. I was thinking of some Alert-Info option that would let the phone reply with a 302 Moved Temporarily or 182 Queued message and not let the phone ring or display anything on its screen. According to the SIP RFC, a SIP endpoint is supposed to respond to an OPTIONS message the same way that it would respond to an INVITE message with the identical destination, but I've never seen a phone respond to an OPTIONS message with anything but '200 OK', even when a redirect (forward) is in place. So, the alternative option is to play with html and use phone embedded html server to get this redirection data. Cheers -- Kevin P. Fleming Director of Software Technologies Digium, Inc. - The Genuine Asterisk Experience (TM) ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] How to check if a SIP phone is forwardedwithout ringing it ?
This issue of phone vendors not supporting OPTIONS according to RFC 3261 often comes up on this list. Like Kevin Fleming said, an OPTIONS request is supposed to be responded in the same way as an INVITE. Almost all SIP phone vendors have construed OPTIONS as some kind of a keep-alive request, which is wrong. Can we ask the phone vendors to play by the book? -- Raj From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Olivier Sent: Tuesday, January 08, 2008 7:50 AM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] How to check if a SIP phone is forwardedwithout ringing it ? 2008/1/7, Kevin P. Fleming [EMAIL PROTECTED]: Olivier wrote: Is there way for an Asterisk server to check if a sip phone is forwarded without bothering phone's user ? No. I was thinking of some Alert-Info option that would let the phone reply with a 302 Moved Temporarily or 182 Queued message and not let the phone ring or display anything on its screen. According to the SIP RFC, a SIP endpoint is supposed to respond to an OPTIONS message the same way that it would respond to an INVITE message with the identical destination, but I've never seen a phone respond to an OPTIONS message with anything but '200 OK', even when a redirect (forward) is in place. So, the alternative option is to play with html and use phone embedded html server to get this redirection data. Cheers -- Kevin P. Fleming Director of Software Technologies Digium, Inc. - The Genuine Asterisk Experience (TM) ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] b2bua
No, that is not correct. The RTP has to be established first to flow through Asterisk, and only then may the RTP be renegotiated to flow direct. This first step is NOT optional. What about directrtpsetup=yes? -- Raj ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] How to automaticaly close calls whenAsterisk didn't receive the bye request ?
The rtptimeout feature has a few limitations: . It is ineffective when the RTP is not terminated on Asterisk. . It can cause false session hangups if the remote SIP UA does not support silence suppression . The companion rtpholdtimeout can cause false hangups if you make incorrect judgment on how long a call hold can last. . The rtptimeout period is not negotiated throughout the SIP signaling path i.e. between the UAC, UAS, and intermediary proxies. So it does not help clear the session state throughout the network (when your BYE doesn't make it to all the entities in the SIP signaling path). The SIP session-timers feature addresses all of the above limitations. -- Raj Jared, I would think of using rtptimeout. There is a reason why you did not mention it and I am curious as to why. ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Asterisk SIP handling - why 491 Request Pending response
Olle, You're right. I missed one thing when I concluded that this was an INVITE glare condition, which is that when the UAC and UAS dialogs are matched they're compared with respect to their LOCAL and REMOTE tags as opposed to the To and From tags. The LOCAL and REMOTE tags will get filled either with To or From tag depending on whether you're looking at the dialog from the UAC or from the UAS. So, in this case you'll have two dialogs in Asterisk and they'll have the same Call-Id but their tags will be swapped. Do you think Asterisk dialog matching is coded to handle this? While we've not seen a trace yet, it'd seem like we're missing something because we're sending back a 491. Raj On Dec 23, 2007 2:21 AM, Johansson Olle E [EMAIL PROTECTED] wrote: 23 dec 2007 kl. 01.45 skrev Raj Jain: You can not do this. You can not have an INVITE that Asterisk originated enter back into Asterisk. Technically this is not a loop, but this is an INVITE glare and the way Asterisk is reacting is correct. You'll need to change the Call-Id of the INVITE that goes into Asterisk (a proxy can not do that so you'll need a B2BUA), or else you can do something like what Olle suggested. I don't really agree here Raj. Of course you can send an INVITE to an URI hosted by the proxy and the location table points back to one or several URI's in the same Asterisk server. /O ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Asterisk SIP handling - why 491 Request Pending response
You may want to try setting pedantic=yes in your sip.conf and retest this. The following traces would be helpful: sip set debug on core set debug 10 core set verbose 10 You may want to open a bug in bug tracker and upload your config and log files over there. -- Raj On Dec 23, 2007 7:47 AM, Tomasz Zieleniewski [EMAIL PROTECTED] wrote: it seems that asterisk in not cheking tags in to and from headers. When asterisk responds to the second INVITE it puts again the same tag in the To header: tag=as62247c57 what kind of trace can I catch to have more details here? On Dec 23, 2007 12:51 PM, Raj Jain [EMAIL PROTECTED] wrote: Olle, You're right. I missed one thing when I concluded that this was an INVITE glare condition, which is that when the UAC and UAS dialogs are matched they're compared with respect to their LOCAL and REMOTE tags as opposed to the To and From tags. The LOCAL and REMOTE tags will get filled either with To or From tag depending on whether you're looking at the dialog from the UAC or from the UAS. So, in this case you'll have two dialogs in Asterisk and they'll have the same Call-Id but their tags will be swapped. Do you think Asterisk dialog matching is coded to handle this? While we've not seen a trace yet, it'd seem like we're missing something because we're sending back a 491. Raj On Dec 23, 2007 2:21 AM, Johansson Olle E [EMAIL PROTECTED] wrote: 23 dec 2007 kl. 01.45 skrev Raj Jain: You can not do this. You can not have an INVITE that Asterisk originated enter back into Asterisk. Technically this is not a loop, but this is an INVITE glare and the way Asterisk is reacting is correct. You'll need to change the Call-Id of the INVITE that goes into Asterisk (a proxy can not do that so you'll need a B2BUA), or else you can do something like what Olle suggested. I don't really agree here Raj. Of course you can send an INVITE to an URI hosted by the proxy and the location table points back to one or several URI's in the same Asterisk server. /O ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Enable/Disable Sip without registration
On Dec 12, 2007 8:01 AM, equis software [EMAIL PROTECTED] wrote: I try to configure that only registered sips can make calls. How can I do that? Registrations are meant for routing calls to end-points, not for accepting calls from end-points. I don't think Asterisk supports a mechanism which allows only registered end-points to make calls. -- Raj ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Asterisk SIP handling - why 491 Request Pending response
You can not do this. You can not have an INVITE that Asterisk originated enter back into Asterisk. Technically this is not a loop, but this is an INVITE glare and the way Asterisk is reacting is correct. You'll need to change the Call-Id of the INVITE that goes into Asterisk (a proxy can not do that so you'll need a B2BUA), or else you can do something like what Olle suggested. Thanks, Raj On Dec 22, 2007 9:51 AM, Tomasz Zieleniewski [EMAIL PROTECTED] wrote: Hi, The message that asterisk receives is not a retransmission but this is the same message but it enters asterisk from other sip proxy which is not a loop. The flow is the following Asterisk SIP Proxy (Location Service) INVITE (to registrar) - INVITE (to voicemail when not registered) when message enters asterisk for the second time it ofcorse has some extra SIP specific header like Record-Route and Via and the Request-URI is changed. And this causes 491 response. Can I do something about this? Can this behaviour be controlled, what do I have to change in the message so that asterisk won't treat it with 491 response? Thanks Tomasz On Dec 21, 2007 7:28 PM, Terry Wilson [EMAIL PROTECTED] wrote: What is the reason for such response? SIP/2.0 491 Request Pending Via: SIP/2.0/UDP 192.168.129.74:5160;branch=z9hG4bK17c3.17db29e7.0 ;received=192.168.129.74 Via: SIP/2.0/UDP 192.168.129.74 ;branch=z9hG4bK17c3.23083974.0 Via: SIP/2.0/UDP 192.168.129.74:5070;branch=z9hG4bK5b33ae78;rport=5070 From: IPFon sip:[EMAIL PROTECTED]:5070 ;tag=as7217acbc To: sip:[EMAIL PROTECTED];tag=as7217acbc Call-ID: [EMAIL PROTECTED] CSeq: 102 INVITE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces Content-Length: 0 X-Asterisk-HangupCause: Normal Clearing X-Asterisk-HangupCauseCode: 16 Asterisk will send a 491 Request Pending when it is currently processing an INIVTE on a particular call and it gets another INVITE that isn't a retransmission. ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] get SIP extension status without calling it
In theory, UAs that respond to OPTIONS and INVITE differently are broken. Below is a quote from section 11.2 of RFC 3261. The response to an OPTIONS is constructed using the standard rules for a SIP response as discussed in Section 8.2.6. The response code chosen MUST be the same that would have been chosen had the request been an INVITE. That is, a 200 (OK) would be returned if the UAS is ready to accept a call, a 486 (Busy Here) would be returned if the UAS is busy, etc. This allows an OPTIONS request to be used to determine the basic state of a UAS, which can be an indication of whether the UAS will accept an INVITE request. In practice, as you're seeing it yourself most UA implementations treat OPTIONS as a health-check and capability discovery mechanism. - Raj -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Vieri Sent: Sunday, December 02, 2007 12:57 PM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] get SIP extension status without calling it I tried another popular user agent: X-Lite. I dialed *78 which in */FreePBX turns DND on AND I pushed the DND button on the softphone. # asterisk -vvvr CLI database show dnd /DND/4053 : YES Despite all this when I send an OPTIONS request I always get a 200 ok reply. Is X-Lite also broken with respect to the SIP RFC? Or am I doing things wrong? # ./options -1 -a --method OPTIONS sip:[EMAIL PROTECTED]:6486 SIP/2.0 200 OK Via: SIP/2.0/UDP 10.215.144.27:38102;branch=z9hG4bKZDm0j0KD5BSBQ Contact: sip:10.215.147.240:6486 To: sip:[EMAIL PROTECTED];tag=681c6278 From: sip:10.215.144.27;tag=Z1QHmBt52Dp1Q Call-ID: 6b9f7f35-1ba1-122b-d4b7-00c09f10e472 CSeq: 92190473 OPTIONS Accept: application/sdp Accept-Language: en Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO User-Agent: X-Lite release 1011s stamp 41150 Content-Length: 0 CLI sip show peer 4053 INF-VOIP*CLI * Name : 4053 Secret : Set MD5Secret: Not set Context : from-internal Subscr.Cont. : Not set Language : es AMA flags: Unknown CallingPres : Presentation Allowed, Not Screened Callgroup: 2 Pickupgroup : 2 Mailbox : [EMAIL PROTECTED] VM Extension : asterisk LastMsgsSent : 0/0 Call limit : 0 Dynamic : Yes Callerid : device 4053 Expire : 3597 Insecure : no Nat : Always ACL : No CanReinvite : No PromiscRedir : No User=Phone : No Trust RPID : No Send RPID: No DTMFmode : rfc2833 LastMsg : 0 ToHost : Addr-IP : 10.215.147.240 Port 6486 Defaddr-IP : 0.0.0.0 Port 5060 Def. Username: 4053 SIP Options : (none) Codecs : 0x400 (ilbc) Codec Order : (ilbc) Status : OK (169 ms) Useragent: X-Lite release 1011s stamp 41150 Reg. Contact : sip:[EMAIL PROTECTED]:6486;rinstance=ff64e47c4f35bdef __ __ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs __ __ Be a better pen pal. Text or chat with friends inside Yahoo! Mail. See how. http://overview.mail.yahoo.com/ ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] SIP response time in Asterisk
In what amount of time does 100 Trying message have to be sent to asterisk? I see asterisk retransmitting the INVITE message multiple times before receiving the 100 Trying message. The INVITEs are retransmitted based on a timer T1, which starts at a default of 500 ms and then exponentially backoffs and caps at 64*T1. The first INVITE retransmission is supposed to happen in 500 ms. However, Asterisk has a minor bug in this place. Asterisk sends the first INVITE retransmission after 1 second instead of 500 ms. This means Asterisk will wait for a second for a response such as 100 Trying before it will start retransmitting the INVITE. Asterisk will retransmit the INVITE after 1, 1, 2, 4, 8, 16, 32 seconds (ideally, this should be 500ms, 1, 2, 4, 8, 16, 32) from the start if it doesn't see a response. Raj --- David Boyd [EMAIL PROTECTED] wrote: On Fri, 2007-10-26 at 11:12 -0700, John Riek wrote: I need to know how fast a sip device needs to respond to an INVITE sip message from asterisk before asterisk retransmits the INVITE message again. Thanks Snip --- 7.2.1 INVITE received When an INVITE request is received by the gateway, a 100 Trying response MAY be sent back to the SIP network indicating that the gateway is handling the call. The necessary hardware resources for the media stream MUST be reserved in the gateway when the INVITE is received, since an IAM message cannot be sent before the resource reservation (especially TCIC selection) takes place. Typically the resources consist of a time slot in an E1/T1 and an RTP/UDP port on the IP side. Resources might also include any quality-of-service provisions (although no such practices are recommended in this document). ** After sending the IAM the timer T7 is started. The default value of T7 is between 20 and 30 seconds. The gateway goes to the 'Trying' state. ** ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Getting SIP Response Code from HANGUPCAUSE
http://www.faqs.org/rfcs/rfc3398.html The conversion is lossy. More than 1 SIP cause code is mapped to a Q.931 cause code (in Asterisk at least). See hangup_sip2cause() in chan_sip.c True. The conversion is lossy in that respect and most of the times semantically incorrect simply because of the fundamental differences between SIP and ISUP. In fact, many new SIP response codes have been defined and will be defined in the future since RFC 3398 was written (http://www.iana.org/assignments/sip-parameters). And as far as I can tell a revision of RFC 3398 is not in works in the IETF. - Raj -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Philipp Kempgen Sent: Friday, October 26, 2007 11:37 AM To: Asterisk Users Subject: Re: [asterisk-users] Getting SIP Response Code from HANGUPCAUSE Eric ManxPower Wieling wrote: On 10/25/07, Douglas Garstang [EMAIL PROTECTED] wrote: I'd like to grab the SIP response code that comes back from an INVITE. The HANGUPCAUSE gives the converted ISDN cause code. Anyone know of a way to get the SIP response code instead? There is an RFC for this. I don't know if Asterisk follows the RFC or not. http://www.faqs.org/rfcs/rfc3398.html The conversion is lossy. More than 1 SIP cause code is mapped to a Q.931 cause code (in Asterisk at least). See hangup_sip2cause() in chan_sip.c Regards, Philipp Kempgen -- amooma GmbH - Bachstr. 126 - 56566 Neuwied - http://www.amooma.de Let's use IT to solve problems and not to create new ones. Asterisk? - http://www.das-asterisk-buch.de Geschäftsführer: Stefan Wintermeyer Handelsregister: Neuwied B 14998 ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Getting SIP Response Code from HANGUPCAUSE
The only place where it is reasonable to customize is in the specification of the channel in the configuration file. That is where you would customize, for example, whether DTMF is inband, SIP INFO, or RFC 2833, as well as what codecs will be negotiated for that particular user/peer. But you already have the SIP_HEADER function, which is quite contradictory to what you say. This allows users who know what they are doing to examine headers directly. We use this a lot. What would be the harm in having a SIP_RESPONSE function or something alike? I'd agree that SIP response code should be accessible from the dial plan. Knowing the exact SIP response code could be critical for making call processing decisions. The conversion of SIP response codes to Q.931 codes (HANGUPCAUSE) is just too lossy. Building a truly protocol agnostic dial plan API is a worthy goal. But, I think it is somewhat of an unsolvable problem. The signaling protocols are very different and for various reasons people have always wanted access to native information elements carried in the protocol. Perhaps, a very simple solution for this problem could be to support a keyword such as TOPLINE in the SIP_HEADER function to fetch the topmost line in a SIP message. This will not only get the caller the response code for SIP response messages, but will also have the nice byproduct of making the Request-URI available if the message in question is a SIP request. - Raj ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Good Book to learn SIP
I am trying to learn SIP in its entirety. I have so far found: http://www.amazon.com/SIP-Demystified-Gonzalo-Camarillo/dp/0071373403 http://www.amazon.com/SIP-Demystified-Gonzalo-Camarillo/dp/0071373403 Learning SIP in its entirety is a worthy goal. The current SIP protocol suite is covered in 75+ RFCs to date. The RFC 3261 alone (the largest RFC the IETF has ever produced) which covers only the core SIP is 269 pages long. A book that I've found particularly useful in SIP is the following: http://www.amazon.com/SIP-Beyond-VoIP-Communications-Revolution/dp/097481300 1 Thanks, Raj Jain I am trying to learn SIP in its entirety. I have so far found: http://www.amazon.com/SIP-Demystified-Gonzalo-Camarillo/dp/0071373403 http://www.amazon.com/SIP-Demystified-Gonzalo-Camarillo/dp/0071373403 http://www.amazon.com/SIP-Demystified-Gonzalo-Camarillo/dp/0071373403 Anyone know of any other books that are worth reading ? Thanks. Justin The RFCs are online as well as anything else you could want to know. Are you just a book person? Thanks, Steve Totaro ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Multi-sip rings
Adrian, You are right about last-come-last-known registration. I guess the phone is sending multiple 180 messages. A SIP debug trace will help identify this. Raj On 9/19/07, Adrian Marsh [EMAIL PROTECTED] wrote: Hi All, Can anyone tell me how the below can be happening? -- SIP/205-08439ee0 is ringing -- SIP/405-084468f8 is ringing -- SIP/405-084468f8 is ringing -- SIP/405-084468f8 is ringing -- SIP/405-084468f8 is ringing Where, according to A*k, its ringing the same SIP device at the same time, 4 times.. ? If a client logs on from several IPs, its last-come-last-known - right? So there should only be one SIP/405 registered. ___ Sign up now for AstriCon 2007! September 25-28th. http://www.astricon.net/ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Prevent multiple sip registrations
On 9/11/07, Rizwan Hisham [EMAIL PROTECTED] wrote: My requirement is to prevent registrations for aan account if that account is already registered with a user. That is a perfectly valid requirement. This is not a SIP protocol issue. This is a SIP Registrar implementation/policy issue. If a SIP Registrar implementation could limit the number of Contact bindings per AoR then this goal can be accomplished. Asterisk's SIP Registrar does not support this today. However, it should be a relatively minor enhancement to add this in the Asterisk SIP Registrar itself (as opposed to implementing this through back-end database hooks). As an example, the OpenSER's SIP Registrar supports a parameter called max_contact to accomplish the same goal: http://www.openser.org/docs/modules/1.2.x/registrar.html#AEN199 Raj ___ Sign up now for AstriCon 2007! September 25-28th. http://www.astricon.net/ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] rfc3680, reginfo+xml
Olivier, In principle, Registration/Presence and Call-Processing are separate logical functions but for cost or other reasons one could combine them in one software implementation or one physical box. For most parts, Asterisk is the Registrar in a SIP network and therefore maintains the location table. So, whatever entity runs the RFC 3680 notifier function will need access to Asterisk's location table. This is not the real issue though (the access to this table can be easily granted through the API). The answer to whether RFC 3680 should be built inside Asterisk or outside of it really depends on the kind of scalability one is looking for. The scalability here refers to the number of subscriptions per each AoR (notification fan-out). Basically, you don't want to overload Asterisk with excessive number of subscriptions to the extent that they can negatively impact call/media processing. If you compare this with presence, the PUBLISH method allowed the presentity to inform only one entity (the presence server) of its state changes. The presence server was the one that did the drudgery of maintaining individual subscriptions and notifying the watchers. The presence model assumes that there are multiple watchers subscribing to the state of *a* presentity. RFC 3680 is a bit different than this, however. If you are looking to do free-seating using RFC 3680, I'd imagine that you will need only one subscription for each AoR in Asterisk (so you don't really have a 1:n fan-out issue). In that case, it is probably okay if the RFC 3680 'notifier' function was embedded within Asterisk itself. The current RFC 3265 support in Asterisk code should make the job of supporting RFC 3680 a bit easier. Raj From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Olivier Sent: Wednesday, August 22, 2007 8:27 AM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] rfc3680, reginfo+xml Thanks for replying, Raj. Do you think such feature should, ideally, be implemented in Asterisk should it be implemented in a dedicated software (presence ?) ? It seems to me it should, though I'm not aware of many devices using this feature, beside SIP hardphones. Would it be difficult to extend current code to comply with this RFC, when rfc3265 mechanism is already in place ? ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] rfc3680, reginfo+xml
Olivier, This feature is not supported in Asterisk. I can tell this looking at the code. If you want to test this yourself, send Asterisk a SUBSCRIBE message with Event: reg header in it. You can either use an off-the-shelf UA that supports RFC 3680 to do this or you can use SIPp (an open-source SIP test tool) to do this. Since Asterisk does not support reg event-package, it'll respond back with a 489 (Bad Event) response. Raj On 8/22/07, Olivier [EMAIL PROTECTED] wrote: Hi, RFC3680 defines a SIP event package for registration. This event package which can be used through NOTIFY-SUBSCRIBE methods, seems very useful for free sitting or presence applications. This package is supported in various SIP phones (at least Thomson ST2030) : when turned on, this feature adds a new login/logout menu among other things. It can also be used to send Welcome notices to mobile users : whenever a mobile user comes in, a SIP MESSAGE is sent by a software application which has previously subscribed to be notified of any registration event related to this mobile user. It appears Asterisk supports SIP NOTIFY-SUBSCRIBE methods. But I couldn't find any trace of this specific Registration Event package support (but I won't swear I searched the right way). How can I make sure this feature is supported or not ? More precisely, this Registration Event package support relies on these headers : SIP SUBSCRIBE reg Event SIP SUBSCRIBE application/reginfo+xml Accept SIP NOTIFY reg Event SIP NOTIFY application/reginfo+xml Content How shall I check ? Regards ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] 180 Ringing with SDP
180 w/ SDP is valid, although not ideal. 183 w/ SDP is a better choice for early-media. The SIP specifications do not dictate what a UAC should do when it receives 180 w/ SDP. It depends on the policy implemented in the UAC. As far as Asterisk is concerned, it could treat 180 w/ SDP same as 183 w/ SDP. However, there should be a global flag in sip.conf that controls whether SDP in 180 should be interpreted (early media played) or ignored (local ring back generated). Here is a sample policy from RFC 3960 (this doesn't exactly talk about 180 w/ SDP but suggests what a UAC can do when it receives early-media packets in conjunction w/ a 180 response): With this in mind, a UAC should develop its local policy regarding local ringing generation. For example, a POTS (Plain Old Telephone Service)-like SIP User Agent (UA) could implement the following local policy: 1. Unless a 180 (Ringing) response is received, never generate local ringing. 2. If a 180 (Ringing) has been received but there are no incoming media packets, generate local ringing. 3. If a 180 (Ringing) has been received and there are incoming media packets, play them and do not generate local ringing. Note that a 180 (Ringing) response means that the callee is being alerted, and a UAS should send such a response if the callee is being alerted, regardless of the status of the early media session. Thanks, Raj -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alex Balashov Sent: Monday, June 18, 2007 8:27 PM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [asterisk-users] 180 Ringing with SDP On Mon, 18 Jun 2007, Jared Smith wrote: I could be totally off base here, but it's my understanding that a 180 is telling Asterisk to generate ringing on it's side, and that a 183 (with SDP) would tell Asterisk that the call is progressing and that it should play the early media specified in the SDP. I'm sure someone there's probably someone on the list who is more intimate with the details of SIP that can enlighten us further on the subtle differences between the 180 and 183 provisional responses. A cursory interpretation of the RFC suggests that 180 Ringing is a message designed solely to convey ringback, and that it is the payload of the 183 response that may be used to convey additional details about the nature of the call's progress. Therefore, a 180 would be an inappropriate vehicle for early media SDP information. 21.1.5 183 Session Progress The 183 (Session Progress) response is used to convey information about the progress of the call that is not otherwise classified. The Reason-Phrase, header fields, or message body MAY be used to convey more details about the call progress. -- Alex -- Alex Balashov Evariste Systems Web: http://www.evaristesys.com/ Tel: +1-678-954-0670 Direct : +1-678-954-0671 ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] 180 Ringing with SDP
A cursory interpretation of the RFC suggests that 180 Ringing is a message designed solely to convey ringback, and that it is the payload of the 183 response that may be used to convey additional details about the nature of the call's progress. Therefore, a 180 would be an inappropriate vehicle for early media SDP information. Tell that to level 3. :) 180 w/ SDP is valid. ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] SIP kpml DTMF support in *
KPML is now an RFC -- http://www.ietf.org/rfc/rfc4730.txt Asterisk doesn't support KPML today. That doesn't mean it can not be developed if there is sufiicient interest. The true value of adding KPML support in Asterisk is when it is acting as a 'softswitch' (call controller without media hairpin) such that it can install a digit map and collect digits from end-points over the signaling path. Raj On 4/19/07, Grigoriy Puzankin [EMAIL PROTECTED] wrote: Hi, I'm trying to connect Asterisk 1.4 and Cisco CallManager 5 using SIP Trunk without MTP (media termination point). Howerver, Cisco 79xx phones do not support RFC2833, they always notify CCM5 via SKINNY channel no matter where they send RTP to. For non-MTP trunk there's Out-of-band DTMF support in CCM5 called kpml. I wonder if Asterisk can support it. I found an intertnet-draft for kpml: http://tools.ietf.org/id/draft-ietf-sipping-kpml-07.txt, but it seems to be very old - Expires June 25, 2005. I know that using MTP in SIP Trunk at CCM5 makes DTMF work in RFC2833, but MTP resource is very limited and I don't want to proxy RTP via CCM5. Please, do not offer to use H.323. Thanks in advance. Grigoriy. ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] SDP bug
Olle, Regarding project Pineapple, I'm curious why rewrite (or refactor) the SIP stack instead of using an open-source one. Did your research show that there is nothing viable out there that'll fit well w/in Asterisk? OpenPBX community is talking about using Sofia-SIP stack, for instance. Raj Well, the whole retransmit engine is flawed in Asterisk, something I will try to fix in pineapple, the project I'm trying to start as a major rework of the SIp channel. See http://www.codename-pineapple.com. The project is stalled due to lack of funding. I have a few sponsors - thank you! - but not enough to dedicate my time for it. ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] SDP bug
Olle, It depends on how strictly the UA adheres to the offer/answer model. The issue would be that a RE-INVITE from Asterisk will have the version number incremented by more than one, which will break the following rule. Quoting from RFC 3264 Section 8: When issuing an offer that modifies the session, the o= line of the new SDP MUST be identical to that in the previous SDP, except that the version in the origin field MUST increment by one from the previous SDP. That said, I agree that most UAs do not check this. What's a bit more alarming fundamentally is that Asterisk is creating a new answer SDP to respond to an INVITE retransmission. An RFC 3261 compliant implementation MUST send an exact copy of the previous SIP response. Anyway, I realize that Asterisk is not inherently RFC 3261 compliant. Raj Asterisk sends 200 OK: o=root 16300 16300 IN IP4 203.89.nnn.nnn Asterisk sends 200 OK (retransmission): o=root 16300 16301 IN IP4 203.89.nnn.nnn Raj, That's an interesting observation. Do you think this will cause any issues? Even though it's not beautiful, I fail to see why a UA would check that. /O ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Asterisk hangs up SIP call after 6 200 retransmits
I found a subtle difference between the two traces you sent (the call that works and the call that gets dropped). This may or may not be what's causing the problem. The call that gets dropped had a retransmission of INVITE from UAC to UAS (and therefore retransmission of 200 OK from UAS to UAC). There is nothing wrong with the re-transmission as such, but I noticed a potential bug in Asterisk in the way it responds to an INVITE retransmission. Asterisk is bumping up the session version number in the retransmitted 200 OK's SDP. This is as if Asterisk is treating the INVITE retransmission as a RE-INVITE. Asterisk sends 200 OK: o=root 16300 16300 IN IP4 203.89.nnn.nnn Asterisk sends 200 OK (retransmission): o=root 16300 16301 IN IP4 203.89.nnn.nnn Ideally, this bug should have nothing to do with why Asterisk is ignoring the ACK (which is why it keeps reatrasmitting the 200 OK and eventually drops the call). However, if you can confirm that all dropped calls have INVITE retransmission then that might give us a clue? Raj On 4/1/07, kjcsb [EMAIL PROTECTED] wrote: One potential reason could be that the ACK request being sent to Asterisk is malformed. Notice branch=0 in the top Via. This should start with z9hG4bK magic cookie since the INVITE was an RFC 3261 transaction. While branch=0 is valid in RFC 2543, I don't think an INVITE can start-off as RFC 3261 and then the ACK can switch over to RFC 2543 in the middle of the transaction. Clearly, Asterisk is dropping this ACK on the floor. OK. But in the calls that don't get dropped, the branch=0 is present also. See below for an example: -- SIP read from 147.202.nnn.nnn:5060: INVITE sip:[EMAIL PROTECTED] SIP/2.0 Record-Route: sip:147.202.nnn.nnn;ftag=as1370b1ab;lr=on Via: SIP/2.0/UDP 147.202.nnn.nnn;branch=z9hG4bK22ab.697375a4.0 Via: SIP/2.0/UDP 202.180.nnn.nnn:5060;branch=z9hG4bK4cf2bb78;rport=5060 From: 649444 sip:[EMAIL PROTECTED];tag=as1370b1ab To: sip:[EMAIL PROTECTED] Contact: sip:[EMAIL PROTECTED] Call-ID: [EMAIL PROTECTED] CSeq: 102 INVITE User-Agent: Asterisk PBX Max-Forwards: 69 Date: Mon, 02 Apr 2007 03:37:54 GMT Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Content-Type: application/sdp Content-Length: 338 v=0 o=root 11402 11402 IN IP4 202.180.nnn.nnn s=session c=IN IP4 202.180.nnn.nnn t=0 0 m=audio 39686 RTP/AVP 18 97 3 0 8 101 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:97 iLBC/8000 a=rtpmap:3 GSM/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=silenceSupp:off - - - - --- (15 headers 15 lines) --- Using INVITE request as basis request - [EMAIL PROTECTED] Sending to 147.202.nnn.nnn : 5060 (non-NAT) Found peer 'DLS' Found RTP audio format 18 Found RTP audio format 97 Found RTP audio format 3 Found RTP audio format 0 Found RTP audio format 8 Found RTP audio format 101 Peer audio RTP is at port 202.180.nnn.nnn:39686 Found description format G729 Found description format iLBC Found description format GSM Found description format PCMU Found description format PCMA Found description format telephone-event Capabilities: us - 0xc (ulaw|alaw), peer - audio=0x50e (gsm|ulaw|alaw|g729|ilbc)/video=0x0 (nothing), combined - 0xc (ulaw|alaw) Non-codec capabilities: us - 0x1 (telephone-event), peer - 0x1 (telephone-event), combined - 0x1 (telephone-event) Looking for 649977 in from-trunk (domain 203.89.nnn.nnn) list_route: hop: sip:147.202.nnn.nnn;ftag=as1370b1ab;lr=on Transmitting (no NAT) to 147.202.nnn.nnn:5060: SIP/2.0 100 Trying Via: SIP/2.0/UDP 147.202.nnn.nnn;branch=z9hG4bK22ab.697375a4.0;received= 147.202.nnn.nnn Via: SIP/2.0/UDP 202.180.nnn.nnn:5060;branch=z9hG4bK4cf2bb78;rport=5060 From: 649444 sip:[EMAIL PROTECTED];tag=as1370b1ab To: sip:[EMAIL PROTECTED] Call-ID: [EMAIL PROTECTED] CSeq: 102 INVITE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Contact: sip:[EMAIL PROTECTED] Content-Length: 0 --- -- Goto (ivr-3,s,1) -- Executing Set(SIP/649977-b7908550, LOOPCOUNT=0) in new stack -- Executing Set(SIP/649977-b7908550, __DIR-CONTEXT=11000111000) in new stack -- Executing Answer(SIP/649977-b7908550, ) in new stack We're at 203.89.nnn.nnn port 15804 Adding codec 0x4 (ulaw) to SDP Adding codec 0x8 (alaw) to SDP Adding non-codec 0x1 (telephone-event) to SDP Reliably Transmitting (no NAT) to 147.202.nnn.nnn:5060: SIP/2.0 200 OK Via: SIP/2.0/UDP 147.202.nnn.nnn;branch=z9hG4bK22ab.697375a4.0;received= 147.202.nnn.nnn Via: SIP/2.0/UDP 202.180.nnn.nnn:5060;branch=z9hG4bK4cf2bb78;rport=5060 Record-Route: sip:147.202.nnn.nnn;ftag=as1370b1ab;lr=on From: 649444 sip:[EMAIL PROTECTED];tag=as1370b1ab To: sip:[EMAIL PROTECTED];tag=as7ecf44d1 Call-ID: [EMAIL PROTECTED] CSeq: 102 INVITE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Contact: sip:[EMAIL PROTECTED] Content-Type: application/sdp Content-Length: 244 v=0 o=root 16300 16300 IN IP4 203.89.nnn.nnn
Re: [asterisk-users] SIP OPTIONS dialog not understood
OPTIONS/200 messages looks correct. Yes, Asterisk requires the From: header field to contain a valid extension to respond with a 200 to a OPTIONS request (else it'll respond with a 404). Raj On 3/28/07, Steve Edwards [EMAIL PROTECTED] wrote: I'm (still) trying to get my Asterisk box talking to a Metaswitch. All I'm getting is a heartbeat of OPTIONS messages coming from the Metaswitch which my Asterisk box replies to. The exchange looks like: -- SIP read from 172.b.c.d:5060: OPTIONS sip:[EMAIL PROTECTED]:5060;transport=udp SIP/2.0 Via: SIP/2.0/UDP 172.b.c.d:5060;rport;branch= z9hG4bK-17eb587208b656d9c2fbd516b5e5401e-172.b.c.d-1 Allow-Events: message-summary Allow-Events: refer Allow-Events: dialog Allow-Events: line-seize Max-Forwards: 70 Call-ID: [EMAIL PROTECTED] From: sip:[EMAIL PROTECTED]:5060;transport=udp;tag=172.b.c.d+1+0+22022a3b CSeq: 445762257 OPTIONS Organization: Supported: 100rel Content-Length: 0 Contact: sip:[EMAIL PROTECTED]:5060;transport=udp To: sip:[EMAIL PROTECTED] --- (15 headers 0 lines) --- Looking for metaswitch in test (domain 206.b.c.d) Transmitting (no NAT) to 172.b.c.d:5060: SIP/2.0 200 OK Via: SIP/2.0/UDP 172.b.c.d:5060;rport;branch= z9hG4bK-17eb587208b656d9c2fbd516b5e5401e-172.b.c.d-1;received=172.b.c.d From: sip:[EMAIL PROTECTED]:5060;transport=udp;tag=172.b.c.d+1+0+22022a3b To: sip:[EMAIL PROTECTED];tag=as6a59273b Call-ID: [EMAIL PROTECTED] CSeq: 445762257 OPTIONS User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Contact: sip:206.b.c.d Accept: application/sdp Content-Length: 0 Is this how OPTIONS is supposed to look? One thing that struck me as curious is that I had to add an extension metaswitch to my test context in my dialplan. Otherwise I got 404's. Can anybody explain (or point to an explanation)? Thanks in advance, Steve Edwards [EMAIL PROTECTED] Voice: +1-760-468-3867 PST Newline Fax: +1-760-731-3000 ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Asterisk hangs up SIP call after 6 200 retransmits
One potential reason could be that the ACK request being sent to Asterisk is malformed. Notice branch=0 in the top Via. This should start with z9hG4bK magic cookie since the INVITE was an RFC 3261 transaction. While branch=0 is valid in RFC 2543, I don't think an INVITE can start-off as RFC 3261 and then the ACK can switch over to RFC 2543 in the middle of the transaction. Clearly, Asterisk is dropping this ACK on the floor. Raj -- SIP read from 147.202.nnn.nnn:5060: ACK sip:[EMAIL PROTECTED] SIP/2.0 Record-Route: sip:147.202.nnn.nnn;ftag=as4917b107;lr=on Via: SIP/2.0/UDP 147.202.nnn.nnn;branch=0 Via: SIP/2.0/UDP 202.180.nnn.nnn:5060;branch=z9hG4bK61752efe;rport=5060 From: 649444 sip:[EMAIL PROTECTED];tag=as4917b107 To: sip:[EMAIL PROTECTED];tag=as7cefaa53 Contact: sip:[EMAIL PROTECTED] Call-ID: [EMAIL PROTECTED] CSeq: 102 ACK User-Agent: Asterisk PBX Max-Forwards: 69 Content-Length: 0 --- (12 headers 0 lines) --- Retransmitting #6 (no NAT) to 147.202.nnn.nnn:5060: SIP/2.0 200 OK Via: SIP/2.0/UDP 147.202.nnn.nnn;branch=z9hG4bKd0e3.48331fd3.0;received= 147.202.nnn.nnn Via: SIP/2.0/UDP 202.180.nnn.nnn:5060;branch=z9hG4bK3757e55c;rport=5060 Record-Route: sip:147.202.nnn.nnn;ftag=as4917b107;lr=on From: 649444 sip:[EMAIL PROTECTED];tag=as4917b107 To: sip:[EMAIL PROTECTED];tag=as7cefaa53 Call-ID: [EMAIL PROTECTED] CSeq: 102 INVITE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Contact: sip:[EMAIL PROTECTED] Content-Type: application/sdp Content-Length: 244 v=0 o=root 16300 16300 IN IP4 203.89.nnn.nnn s=session c=IN IP4 203.89.nnn.nnn t=0 0 m=audio 11648 RTP/AVP 0 8 101 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=silenceSupp:off - - - - --- capetown*CLI -- SIP read from 147.202.nnn.nnn:5060: ACK sip:[EMAIL PROTECTED] SIP/2.0 Record-Route: sip:147.202.nnn.nnn;ftag=as4917b107;lr=on Via: SIP/2.0/UDP 147.202.nnn.nnn;branch=0 Via: SIP/2.0/UDP 202.180.nnn.nnn:5060;branch=z9hG4bK0c397910;rport=5060 From: 649444 sip:[EMAIL PROTECTED];tag=as4917b107 To: sip:[EMAIL PROTECTED];tag=as7cefaa53 Contact: sip:[EMAIL PROTECTED] Call-ID: [EMAIL PROTECTED] CSeq: 102 ACK User-Agent: Asterisk PBX Max-Forwards: 69 Content-Length: 0 --- (12 headers 0 lines) --- == Spawn extension (ivr-3, s, 7) exited non-zero on 'SIP/649977-b791bb60' -- Executing Hangup(SIP/649977-b791bb60, ) in new stack == Spawn extension (ivr-3, h, 1) exited non-zero on 'SIP/649977-b791bb60' Destroying call '[EMAIL PROTECTED]' capetown*CLI Any advice in resolving this issue would be greatly appreciated. Regards Cameron ___ What kind of emailer are you? Find out today - get a free analysis of your email personality. Take the quiz at the Yahoo! Mail Championship. http://uk.rd.yahoo.com/evt=44106/*http://mail.yahoo.net/uk ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
