I'm using 'subst' in multiline mode - basically using it to rewrite a 'Refer-To' header based on the contents of the 'Contact' header. However, if I do that, it looks like all the default processing that occurs on the message (specifically, the addition of a 'Via' header), gets tacked on to the end of the message. It almost looks like all the changes that were made to the message end up in a buffer that gets appended to the end of the message, and *not* as part of the message.
In the example below, I just used the following to generate the error condition subst('/(.*)5100(.*)/\15100aptela\2/si');
And yes, I know that the above doesnt need the 's' flag. Its just that i've distilled my ridiculously complex 'subst' expressiond down to the above really simple expression which still causes the error below.
So, the question is, is this actually supposed to work? Anyone ever actually tried this out?
e.g. incoming packet is (note that th "Refer-To" line sez 'sip:5100@...'. This will get changed to sip:5100aptela@...
REFER sip:7732206484@66.23.129.219:5090 SIP/2.0. f: sip:operator.aptela@voice.aptela.com;tag=7f1ca8c0-13c442ad79d2. t: "7732206484"sip:7732206484@66.23.129.219:5090;tag=as10a69cf8. Call-ID: 6bfbb1d627b2c0366bb2be7206177cea@66.23.129.219. CSeq: 2 REFER. Via: SIP/2.0/UDP 192.168.28.127:5060;rport;branch=z9hG4bK-42ad79d6-1750412-5e02. Max-Forwards: 70. Supported: 100rel,replaces. Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE. User-Agent: SIP Phone-1.0.41 - ABP. Contact: sip:operator.aptela@64.81.147.138:33049. Route: sip:69.25.47.134;lr;ftag=as10a69cf8. Referred-By: sip:operator.aptela@voice.aptela.com. Refer-To: sip:5100@voice.aptela.com. Content-Length: 0. .
outgoing packet *should* be (note the Refer-To line now
REFER sip:7732206484@66.23.129.219:5090 SIP/2.0. Record-Route: sip:69.25.47.134;ftag=7f1ca8c0-13c442ad79d2;lr=on. f: sip:operator.aptela@voice.aptela.com;tag=7f1ca8c0-13c442ad79d2. t: "7732206484"sip:7732206484@66.23.129.219:5090;tag=as10a69cf8. Call-ID: 6bfbb1d627b2c0366bb2be7206177cea@66.23.129.219. CSeq: 2 REFER. Via: SIP/2.0/UDP 69.25.47.134;branch=z9hG4bKfd4a.00e82c93.0. Via: SIP/2.0/UDP 192.168.28.127:5060;received=64.81.147.138;rport=33049;branch=z9hG4bK-42ad79d6-1750412-5e02. Max-Forwards: 16. Supported: 100rel,replaces. Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE. User-Agent: SIP Phone-1.0.41 - ABP. Contact: sip:operator.aptela@64.81.147.138:33049. Route: sip:69.25.47.134;lr;ftag=as10a69cf8. Referred-By: sip:operator.aptela@voice.aptela.com. Refer-To: sip:5100aptela@voice.aptela.com. Content-Length: 0.
but, instead, is
REFER sip:7732206484@66.23.129.219:5090 SIP/2.0. Record-Route: sip:69.25.47.134;ftag=7f1ca8c0-13c442ad79d2;lr=on. f: sip:operator.aptela@voice.aptela.com;tag=7f1ca8c0-13c442ad79d2. t: "7732206484"sip:7732206484@66.23.129.219:5090;tag=as10a69cf8. Call-ID: 6bfbb1d627b2c0366bb2be7206177cea@66.23.129.219. CSeq: 2 REFER. Via: SIP/2.0/UDP 192.168.28.127:5060;rport;branch=z9hG4bK-42ad79d6-1750412-5e02. Max-Forwards: 16. Supported: 100rel,replaces. Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE. User-Agent: SIP Phone-1.0.41 - ABP. Contact: sip:operator.aptela@64.81.147.138:33049. Route: sip:69.25.47.134;lr;ftag=as10a69cf8. Referred-By: sip:operator.aptela@voice.aptela.com. Refer-To: sip:5100aptela@voice.aptela.com. Content-Length: 0. . Via: SIP/2.0/UDP 69.25.47.134;branch=z9hG4bKfd4a.00e82c93.0. ;received=64.81.147.138;rport=33049
note the two lines at the bottom of the message. These are the additional lines that got changed in the message as it was processed.
Take a message. Any message. Run the following on it (replace the string "5100" with the string "5100aptela", but do match \n) subst('/(.*)5100(.*)/\15100aptela\2/si'); Your headers will get all munged up. Instead of the above, just run the following (dont match \n) subst('/5100/5100aptela/si'); Things work like a charm
Well, I knew that, and ended up doing a variation of the above to meet my requirements.
Soo, in case anyone in textops land cares, if you 'subst' across a whole message, the buffers get quite munged up (for details, see the attachment at the bottom...)
cheers
Kanakatti Mahesh Subramanya wrote:
I'm using 'subst' in multiline mode - basically using it to rewrite a 'Refer-To' header based on the contents of the 'Contact' header. However, if I do that, it looks like all the default processing that occurs on the message (specifically, the addition of a 'Via' header), gets tacked on to the end of the message. It almost looks like all the changes that were made to the message end up in a buffer that gets appended to the end of the message, and *not* as part of the message.
In the example below, I just used the following to generate the error condition subst('/(.*)5100(.*)/\15100aptela\2/si');
And yes, I know that the above doesnt need the 's' flag. Its just that i've distilled my ridiculously complex 'subst' expressiond down to the above really simple expression which still causes the error below.
So, the question is, is this actually supposed to work? Anyone ever actually tried this out?
e.g. incoming packet is (note that th "Refer-To" line sez 'sip:5100@...'. This will get changed to sip:5100aptela@...
REFER sip:7732206484@66.23.129.219:5090 SIP/2.0. f: sip:operator.aptela@voice.aptela.com;tag=7f1ca8c0-13c442ad79d2. t: "7732206484"sip:7732206484@66.23.129.219:5090;tag=as10a69cf8. Call-ID: 6bfbb1d627b2c0366bb2be7206177cea@66.23.129.219. CSeq: 2 REFER. Via: SIP/2.0/UDP 192.168.28.127:5060;rport;branch=z9hG4bK-42ad79d6-1750412-5e02. Max-Forwards: 70. Supported: 100rel,replaces. Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE. User-Agent: SIP Phone-1.0.41 - ABP. Contact: sip:operator.aptela@64.81.147.138:33049. Route: sip:69.25.47.134;lr;ftag=as10a69cf8. Referred-By: sip:operator.aptela@voice.aptela.com. Refer-To: sip:5100@voice.aptela.com. Content-Length: 0. .
outgoing packet *should* be (note the Refer-To line now
REFER sip:7732206484@66.23.129.219:5090 SIP/2.0. Record-Route: sip:69.25.47.134;ftag=7f1ca8c0-13c442ad79d2;lr=on. f: sip:operator.aptela@voice.aptela.com;tag=7f1ca8c0-13c442ad79d2. t: "7732206484"sip:7732206484@66.23.129.219:5090;tag=as10a69cf8. Call-ID: 6bfbb1d627b2c0366bb2be7206177cea@66.23.129.219. CSeq: 2 REFER. Via: SIP/2.0/UDP 69.25.47.134;branch=z9hG4bKfd4a.00e82c93.0. Via: SIP/2.0/UDP 192.168.28.127:5060;received=64.81.147.138;rport=33049;branch=z9hG4bK-42ad79d6-1750412-5e02. Max-Forwards: 16. Supported: 100rel,replaces. Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE. User-Agent: SIP Phone-1.0.41 - ABP. Contact: sip:operator.aptela@64.81.147.138:33049. Route: sip:69.25.47.134;lr;ftag=as10a69cf8. Referred-By: sip:operator.aptela@voice.aptela.com. Refer-To: sip:5100aptela@voice.aptela.com. Content-Length: 0.
but, instead, is
REFER sip:7732206484@66.23.129.219:5090 SIP/2.0. Record-Route: sip:69.25.47.134;ftag=7f1ca8c0-13c442ad79d2;lr=on. f: sip:operator.aptela@voice.aptela.com;tag=7f1ca8c0-13c442ad79d2. t: "7732206484"sip:7732206484@66.23.129.219:5090;tag=as10a69cf8. Call-ID: 6bfbb1d627b2c0366bb2be7206177cea@66.23.129.219. CSeq: 2 REFER. Via: SIP/2.0/UDP 192.168.28.127:5060;rport;branch=z9hG4bK-42ad79d6-1750412-5e02. Max-Forwards: 16. Supported: 100rel,replaces. Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE. User-Agent: SIP Phone-1.0.41 - ABP. Contact: sip:operator.aptela@64.81.147.138:33049. Route: sip:69.25.47.134;lr;ftag=as10a69cf8. Referred-By: sip:operator.aptela@voice.aptela.com. Refer-To: sip:5100aptela@voice.aptela.com. Content-Length: 0. . Via: SIP/2.0/UDP 69.25.47.134;branch=z9hG4bKfd4a.00e82c93.0. ;received=64.81.147.138;rport=33049
note the two lines at the bottom of the message. These are the additional lines that got changed in the message as it was processed.
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-
Kanakatti Mahesh Subramanya