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
